Reflection on hackathons

For first, a Hackathon is a competition where hackers get together to build something cool. Lots of times designers and business people also join and the judging also takes the business side into consideration. Usually justifying how the idea is useful and/or generating revenue and showing some proof that people want it is enough. A hackathon generally takes a weekend. Some are three days, some are two days long. Almost always the venue is open overnight and sleeping is replaced by caffeine.

In other words, some people just like to get together in a room, eat rubbish food, be workaholics and sleep deprived in the hope of building something cool or learning something new. Or winning.

My background on hackathons

I’ve been to plenty of hackathons. 15+. I lost count, really. I won something most of the time, but I also miserably lost other times. It was always fun, though. I’ll discuss both losing and winning, and how the experience differs, or at least for me.

I’ve been in different teams. With friends, with randomers, with both. Big teams, small teams. I sometimes had ideas before, sometimes came up with something on the day, or other times just joined someone else’s team and help build their idea. Teams with clear leaders, or more ad-hoc teams.

I also organised a hackathon, and helped running others.

I’ve learned from these experiences and I’m sharing my thoughts in this post.

There are two ways of going to a hackathon.

Building amazing tech

This is the fun way. You learn a lot. You make friends. You build amazing things. You’re not in the game for the win. You don’t make a winning strategy and your only hope is that the hacky server running on your cheap VPS over SSH from your laptop does not crash because your phone runs out of battery during the demo. You can try new technologies. You go around the tables and help your competition.

You might have complex ides from which you build a fraction. You risk building amazing tech you haven’t tried before. It might fail, but you’re there to learn and have fun.

You end up building projects you’re proud of. Not because their level of completion, but because what you have experienced building them.

You don’t make business plans, powerpoint slides or anything like that. For your demo, you have a cool project that you hope will work, or a fair enough attempt. Either way, you might happily continue update/fix the project after the hackathon.

Unfortunately, plenty of hackathons ignore your technical attempts and the engineering skills of your team, so even though you build the most complex project, you might not get any official reward.

Winning the hackathon

Most of the times, if you build amazing tech that may not work or have direct applications, you lose. You might find things you’ve never tried before and you want to play around. It’s really fun to learn new things. It is also really rewarding as a programmer. But it, generally speaking, won’t grab you the big prize.

It is an unfortunate truth that code is not usually judged at hackathons. This being said, judges do a lot of guesswork to pick the winners.

So the winning strategy is to influence the judges into liking you and believing in your idea. To do this, build an awesome UI and an awesome pitch. If your hack is based on, for example, some idea that you can use a smart classifier to tell cats from dogs in YouTube videos, just hand-pick a few videos. If you actually build the classifier you won’t have any time left to build a nice UI, and the guys at the next table who just built a CRUD website with two models and a really convincing pitch and pretty graphics get the grand prize.

If you want to win, you build dead simple stuff, and do it well. Sell it even better. In the end, only the presentation counts. Don’t fake your demo. Don’t attempt to learn too much. Write shit code that works for the demo. Do not even think of writing that complicated thing you’ve never done before if you’re running for the prize. Is all you need to do a UI to add something in a database and display it later? Perfect. You can do it quickly, then polish the demo to perfection, or add a small extra bit.

You can, of course, mix those two things together. If, for instance, the team is large enough, you might be able to work on amazing tech and someone else can deliver an amazing pitch and make pretty graphics. However, other issues arise, like team mangement - in such a short amount of time is incredibly hard to lead a team, and it gets harder with the size of the team.

I recently found this article, The 10 Types of People You Meet at a Hackathon, and I thought of my progression from Noob to Serial Hackathon Winner. I think it’s more enjoyable and rewarding to be a noob. When you’re in for the win, you focus on the prize and not on the journey. You care less about walking around and talking to new people, trying to solve other people’s problems, etc. It becomes a routine: same tricks, same team, same timeframe, same food, same everything. For me, it became the thing that made me not want to go to hackathons that often. I like winning, but I don’t like sacrificing the fun and learning for it.

Winning is rewarding in itself. It took me some time to realise it’s just temporary. When I look back, I remember better the projects that I built for fun than those that I worked on to win, regardless of the temporary outcome (win or lose).