My First Hackathon wasn't a Complete Disaster...

In fact, it turned out great.

I was at a company hackathon at the end of the last week, and I had some reservations about whether or not it would amount to anything, or if I would even enjoy it. I was skeptical about whether or not my company would make us work overnight unpaid on a project that would end up belonging to the company, and which I had no rights to, or if we would be in a competitive setting, or if there wouldn't be any interesting ideas I cared for, or if my team consisted of people who wouldn't be great to work with. Thankfully, it wasn't that kind of a hackathon, and nobody was forced to stay beyond the usual hours they're paid for, and there was no competition or prize or anything like that, and there were some nice ideas*. As for the teams, I guess it depends on a combination of the kinds of ideas people would gravitate towards, my own choice, some politics, and sheer dumb luck.

 I didn't exactly have any ideas I wanted to work on for the hackathon, because most of the ideas I'm already working on aren't new, or they aren't relevant for my company. I did, however, want to introduce Mithril somehow because I felt it was useful; it's a tiny library (8KB gzipped) and doesn't require any special framework knowledge like Angular does; it's just plain vanilla Javascript. The fact that it's so unopinionated and just Javascript makes it easy to learn. And what better way to introduce Mithril than with a new project where we have yet to decide the technology stack for it. The only problem was that I didn't know what project my company needed it for. Thankfully, somebody else in my company noticed this and came up with an idea where I could introduce Mithril.

That's nice, but now what about the people I'll be working with? From my previous experience working with people in my company, there are definitely people I know I do not want to work with on a project like this. I don't like to work with them because they either don't communicate properly or because they aren't pulling their weight. Having any of those kinds of people in your team on a hackathon can spell disaster. You don't have a lot of leg room to mess about if any one of these people fails at communicating or contributing to the team. You do not want to spend extra time dealing with their shortcomings, because that's extra time that could have been spent on actually working on the hackathon project. I was lucky and the people that ended up my team not only weren't any of these people that I didn't want to work with, but they contributed in ways I wasn't aware of when we started. I may not have worked with them previously, and there was always the chance that it wouldn't have worked out, but it was better for them to have been people I've never worked with before than to be people I know for sure aren't worth working with.

We didn't encounter too much friction introducing Mithril into my team; they didn't mind learning something new, even if they weren't used to it, and it wasn't a serious show stopper. We got a lot done, had something nice to show off at the end, and everybody in my team pulled their weight. Does this mean I'm more receptive to hackathons? Well, not necessarily. The reason this hackathon turned out so nicely was because I got lucky. I was lucky that I had a nice team and none of the people I didn't want to be on my team were on it, and I was lucky that there was an idea that matched what I wanted to introduce to the hackathon. I think hackathons are in a way like any kind of team project; you have to be lucky. Teams don't magically create great things by virtue of being a team; you have to get the right people together or else it doesn't work. If you have a team with people that don't communicate properly or aren't pulling their weight, they aren't going to make anything that amounts to much. It doesn't matter if you put them together and call them a team; it's not going to happen. Not without a lot of blood, sweat and tears. Which is frankly sometimes not even worth the trouble. 

This has always been my experience working in a group. If you never get to choose what team you're on, or you're not sure what your team members are going to be like, whether or not your team succeeds or fails is often just due to sheer dumb luck. I tend to think of hackathons the same way. You just have to get lucky. I probably still wouldn't attend a hackathon if I had a choice. I'm not interested in testing my luck and I already have plenty of other projects to work on anyways.

*Not every idea was nice, or appropriate for the time frame of the hackathon, but at least they weren't the only ones and I didn't have to choose them.