How To Survive A Hackathon
My team came in second at the CityGrid LA Hackathon at CoLoft in Santa Monica this past weekend. We created NTheMiddle, an iPhone app that helps you find a place to meet in between your current location and someone else’s. It’s basic, but I might polish it up over the next weekend or two and toss it in the App Store.
Since this was the first hackathon I ever attended, I figured I’d post some survival tips.
Figure out compensation at the start.
If there are prizes involved, plan out how you’ll cut up the rewards first. Especially if you just met at the event. I’m not sure on what the best method is to split the pie with complete strangers, considering you may find that some do absolutely no work and will still expect their ‘fair’ share. We just divided it based on how much work we thought everyone was going to do.
Check your ego at the door.
It’s more important to complete something than to have your brilliant vision materialize by the end of the weekend. If you see another pitch that you like, ditch your project and join the other team! In my case, I abandoned my idea and became the sole developer on another because I really liked the concept and it seemed possible to do in a weekend.
Stick with it.
The most interesting thing about a hackathon is you go through the entire Paul Graham Startup Curve in 48 hours. Some teams seemed to fall apart during the mini Trough of Sorrow which hits around the second day. Seriously–it’s only 48 hours, get it together. It might not come out the way you wanted, but there’s absolutely no reason to give up on such a short project. Cross the finish line, even if it’s a spectacular failure.
I pretty much ignored my other team members and forged ahead developing the project as it was originally envisioned on the first day. This was easy for me to do since I didn’t have another programmer to debate with. There’s no feature creep allowed in a 48 hour cycle. The most valuable skill in life is to know what to work on and what is a distraction. A hackathon can be a good training exercise to develop this ability.
Don’t be selfish.
Although it’s a competition, there’s no reason to not help others out. Offering a quick bug fix, feature suggestions, or even QA on another team’s project is a good way to meet future collaborators.
You don’t have to win to get value out of it.
Winning is nice, but that’s not the only objective of a hackathon. Hackathons are great places to find developers for other projects or seek new opportunities. It’s also a good way to network with the sponsors. They are usually underwriting the event to scout for talent or new uses for their APIs.
You don’t need to be a hacker to attend a hackathon.
I think only one-third of the attendees at this hackathon were programmers. The rest were, uh, “business” people and other mundanes. However, there are a lot of talents necessary for a successful hackathon project. I know I could have used a decent graphic designer on my team. Some developers were great engineers, but desperately needed an additional member to do the final presentation.
Hackathons are held all over the world. They usually have themes–some are based on a specific technology, others on a type of app. There are resources out there to find hackathons near you if you’re interested in doing one.