I need to begin by saying that I’m no hackathon expert. I’ve partaken in three: one Startup Weekend, as an observer; and two PennApps’s, one very successfully.
I think I’ve recognized some patterns among hackathons. If you’re trying to be successful, some things are just a lot more important than other things–and it’s not what I would have necessarily expected.
Your team matters.
This is the single most important factor in any hackathon. At Startup Weekend Philadelphia, all the impressive teams were the ones loaded with programmers. That said, coders != success. At my first hackathon, my team was stacked with some of the most impressive freshmen at Penn. But our project was lackluster. For one thing, I was the only person excited about doing front end dev–and by the end of the weekend I was exhausted while my teammates often sat around bored.
I picked my team much more successfully the second time around. I found myself working with the best team I could ask for: Drew Inglis and Nick Meyer. Drew is a practiced web developer–he spent a year working at Intersect–and Nick is a strong coder and remarkably quick learner.
More important than our skills alone, however, were the ways in which we complimented each other. Skillwise, I could handle the front end and design while Nick worked on the back; Drew was solid all the way around and acted as a de facto lead developer. Meanwhile, Nick and Drew wanted to stick to coding, while I was happy to handle the “soft” aspects of the project (the pitch, and, much later, the press releases–but that’s another story). Additionally, our personalities were complimentary. Drew and I represent a nice balance of perfectionism vs. quick hacks, respectively. And Drew is technically wise, while Nick’s always receptive to learning new things. As far as I could tell, they make a great pair, and I think the three of us have made a great team.
Your idea doesn’t matter.
Or, at least, it doesn’t matter nearly as much. Honestly, your idea mostly matters insofar as it affects your team. At Startup Weekend Philadelphia, there were plenty of teams that had ideas that weren’t attractive to coders. No matter how appealing those ideas were to business people or to consumers, if the ideas didn’t stick to the devs, the team was doomed. Although Startup Weekend demo day can include demos that are all pitch and no product, those product-less pitches are not very impressive, especially when compared to fully functioning apps and websites.
If you don’t have a solid idea going into the hackathon, don’t sweat. The night before PennApps, we were still telling people we were going to write an app called “Strip Your Friends.” (I don’t think any further explanation is necessary here.)
Your limits matter.
You have a very limited amount of time at a hackathon–so have some idea of what you can really do. Be willing to scale down, and be willing to sacrifice goals. I have a very cursory knowledge of Rails, and I would have loved to learn more this weekend. But I knew that I wasn’t going to be able to learn that much, especially if I wanted to polish my UX. Besides, Drew is a marvelous teacher–he’s explained many CS ideas to me over the years–but I knew I could learn more from him sometime when we weren’t under time pressure.
Your pitch matters.
At PennApps, there are usually upwards of 40 hacks. Will the judges remember you when it’s all done?
The demo can make or break your chances. One of the judges at the spring PennApps later noted that the winning team “greatly exaggerated” their product in their pitch. While you shouldn’t be dishonest, it just goes to show that the demo is the most critical part of the hackathon.
Jokes are good, but don’t get too carried away. At this past PennApps, people got so carried away making jokes about one of the organizers that a lot of the apps started to blend together.
And, if you’re going to pitch, get some sleep, for crying out loud! I have my own sob story about this, but I’ll refrain from telling it.
Details don’t matter.
The flip side of this is simple: Details don’t matter, because, simply, no one will see them. Our app had a remarkable number of elegant details, but we couldn’t show them off in a two minute pitch. Don’t worry about details during a hackathon.
This is another variation on the pitch. After all, your design communicates a lot to the viewer instantly. I’ve seen too many interesting pieces of code flop in front of the judges because they were ugly and badly explained. And ugliness is a variation on a bad explanation.
Code quality doesn’t matter.
The flip side of graphic design is code quality. While this is probably more important to most CS students, this is not something anyone will ever see. It says nothing. As long as your code doesn’t break, don’t worry about it. Of course, if you’re trying to push your product past the hackathon, as we did, you need to pay some attention to robustness and efficiency, but these are often things which can be fixed later. (The big exception to this is database design; if you want your project to live long term, the database needs to solid all the way along.)
Of course, people often have different reasons for participating in hackathons. One of my friends, who is an very gifted programmer with zero web development experience, sees hackathons as a chance to finally learn about web dev, and at lightspeed. Others go just for the atmosphere. At the last PennApps, I had several friends go to just “chill.” Hanging out with people who haven’t slept for upwards of 40 hours just for kicks is not exactly my idea of fun, but some people love it. It is, of course, possible to have a very good hackathon without winning anything or completing a product.
I’m Tess Rinearson, a freshman in Computer Science at the University of Pennsylvania. I’ve interned at Valve and CloudMine, and if you liked this post you should follow me on Twitter. This is the longest blog post I’ve ever written.
You might also like...
Powered by Facebook Comments