Here in San Francisco hackathons are common place — you can find one most every weekend.The basic premise of a hackathon is to show up, build an app in 24-48 hours, and go home. All food and drink is taken care of and sleep is frowned upon, though a couple hours of nap time is suggested. The draw of hackathons, other than the lack of sleep and free food, are the prizes you can win which range anywhere from a few hundred dollars to a million.
For those of you looking to attend a hackathon for the first time, or even you savvy veterans that are looking for another win, here are a few things I’ve picked up during my time at various events:
Seriously, don’t think about prizes during the hackathon.
‘But Yaron! That’s why I go.’
Is it? Or would you rather build a killer app and win the thing? It sounds nuts but you’ll probably build a much better app if you don’t revolve it around a specific technology. Too often we steer ourselves towards the money even though the odds are stacked against us and we don’t love the idea whole heartedly.
At the Launch Hackathon we originally went in with an idea to show users what was in stock nearby because we wanted to win $5000 from Kohl’s. We weren’t set on the idea, but there was $5000 on the line so we started wire-framing. Right before we were ready to begin coding we discovered milo.com…even our layouts were the same. Game, set, and match. Our excitement was depleted and we scrapped everything. A few minutes later we came up with the idea for bartendr.me and never looked back.
bartendr.me team @ Launch Hackathon (L to R)— Yaron, Fab, Nate
Similarly, at another hackathon, I was on a team that built a stock market for NFL Rookies. Venmo was present so we decided to implement it as a way for users to transfer funds easily. Integration was taking a little too long so we went with a simpler product for the purposes of the demonstration. We knew we’d lose the Venmo prize but we didn’t care, we could taste victory.
In the end, without even realizing what we’d done, we had won the $500 Venmo prize.
The main reason I say to forget the prize is that judging comes down to an individual, usually the company’s evangelist, and it’s all subjective. Did they like your app or not? Does your app measure up to the ones they’ve seen in the past? Is there a real use of their service or did you integrate it for the purposes of the prize? Who knows what is going on up there. If you build something you love then your passion will show and the excitement you exude will be contagious.
2. Use pull requests
The first hackathon I ever attended was the Emirates Hackathon. This is the one which taught me the most and showed me the value of utilizing pull requests. Profession aside, when working under a time constraint we tend to make mistakes. In this case, when all you want to do is push code you tend to ignore the details and best practices.
Basic breakdown of a pull request (i.e. PR)
The main benefit of using pull requests is that the more eyes that see the code the better the quality. With a five person team, excess energy drinks, and everyone freely pushing changes we were bound to run into errors — and we did.
The lack of communication between team members caused errors to sprout left and right. On the front-end, element ids and classes were being overridden constantly and driving the JavaScript to throw errors.With pull requests, one must read each line to understand what is going on and can spot an error that was easily glazed over due to tunnel vision. A second set of eyes are the first line of defense against errors reaching the master branch but also reduce the likelihood that code will be overwritten by a teammate and repetitive work from occurring. Discussion on a pull request is also necessary and communication is rarely a bad thing.
3. Test out TDD
After pull requests, tests are your second line of defense. Yes, they can be time consuming, but features are notorious for breaking right before presentations thanks to that last minute push to production.
So close, just one last push…
Talk to anyone in the industry and they’ll tell you that tests have saved them more than once; not to mention all the time saved from having to find the bug.
In fact, at a hackathon, the biggest return a test provides is not having to spend time finding the error. Sure, you’ll spend a couple minutes writing it but the future payoffs are enormous when in a crunch. Not only that, but you’ll get faster at testing the more you do it. Testing will become second nature and your boss will thank you for it. *sniff* *sniff* I smell a raise!!
Never used TDD or have trouble writing tests? Pseudo-code your goals first and then build a few tests that would be most beneficial. Precision isn’t necessary but it will come with time. For you Rails people, I use a gem called SimpleCov. It gives you a quick and dirty breakdown of your testing coverage.
4. Talk to people
Hackathons are as much about building new connections as building a new product. It’s so easy to get deep into your code and ignore everything around you, but take a break once in a while and chat up your fellow programmers and event sponsors. Talk about what you’re building and the technologies you’ve used. By sharing this information you’ll get tips, suggestions, and feedback that you wouldn’t have gotten otherwise. You might even be able to integrate a sponsor’s technology and potentially win their prize!
While at the Launch Hackathon, where we built bartendr.me, we used import.io to scrape data from the web. At the end of it all I shot an email to Andrew Fogg, their CDO,and told him about what we had built with the help of his product. He happened to be at the hackathon and asked us to demo the product for him. He loved the product, invited us to their offices for lunch, and blogged about our app. In a sense, by walking around and talking to people, we’d just created our own prize!
5. Learn new technology
Hackathons are a perfect place to try something new. The stuff you build will likely never be used and if it does then a rebuild is probably in order. Take this time to learn a technology you’ve had your eye on or one that you have little experience in. It’s proven that the best way to learn something new is through immersion and pressure — I think 24 hours to build an app definitely qualifies.
My friend Robbie decided to fly solo during a hackathon and built an app in node.js. He’d had node on his radar for some time and decided that the hackathon was as good a time as ever. After 24 hours he pitched his final product and, though it wasn’t the prettiest, it worked. After all was said and done he attracted the most attention at the end of the event and had people lining up to talk to him.
Pick no more than 1-2 new technologies you want to work with and ideally something that someone else on the team has some experience with. Though not a large challenge, I chose to learn CoffeeScript during my last hackathon and now use it regularly. Why? Here’s an example:
Left: CoffeeScript — Right: JavaScript
Side note: Integrating a sponsor’s product doesn’t count as new technology if you won’t use it again after the hackathon. For example, I rarely build apps utilizing wearable devices so learning Plantronics’ technology wouldn’t be of much use beyond the 24 hours. However, learning to use Iron.io Workers or Twilio benefited me on many projects.
Summary
So, all in all, build/create something you would get behind wholeheartedly . Put a little more effort into making sure it functions properly, tell people about it, and don’t focus too short term. You’ll have a lot more fun and get some amazing training in. You might even build a solid product that could be a new side project. By doing things a bit differently you’ll find that you can get much more out of hackathons other than just free food and no sleep. Try it!
Thanks for reading! You can find me on Twitter - @yaronsadka
In honor of this post Iron.io is hosting a holiday hackathon! The hackathon will begin on Monday, Dec. 23 and end on Monday, Dec. 30. Click on the link for more info and registration!
In honor of this post Iron.io is hosting a holiday hackathon! The hackathon will begin on Monday, Dec. 23 and end on Monday, Dec. 30. Click on the link for more info and registration!