This past weekend I participated in Hack the Midwest, a Kansas City hackathon. The event was a huge success drawing a crowd of around 100 developers. As one of the visiting developer evangelists said, it was a great turnout for a New York hackathon, much less one in the midwest.
At the competition I built Qup.tv, a simple service that will send you email alerts when Netflix adds new titles to its streaming catalog. I was lucky enough to win top honors at the event, but this wasn’t my first rodeo. With three Rails Rumbles, two Node Knockouts, and a Startup Weekend under my belt I’m beginning to get a sense of what works and what doesn’t. So here’s my list of things to keep in mind when competing in a hackathon:
1. Have a Layered Strategy
You will never accomplish everything you set out to complete at a hackathon. Something at some point will take ten times longer than it was supposed to, so you need to plan for having multiple goals any of which could end up being the final product. Your first stage should be something that you expect you can complete in well less than half the time allotted. For example, here was my layered plan for Qup:
- Users can sign in with their Netflix account and will receive emails of the latest Netflix releases
- Users can add items to their queue or watch them with one click from the email. For queueing, users should not have to be logged into Qup or Netflix
- Users can filter based on Netflix rating, Rotten Tomatoes score, and
exclude genres they don’t want updates about - Track usage activity to be able to
show which of the titles are most popular Add in support for Amazon Prime Instant Videos and/or Hulu
Even though my app won I only got through about half of what I thought I might be able to accomplish in 24 hours. I also ended up doing a decent amount of work tracking genres and usage activity which didn’t show up in the final product at all because I didn’t have time to polish and expose it. Which brings me to tip #2.
2. Cut Everything That Doesn’t Work Well
It’s a hackathon so judges will excuse a bug here and there, but regardless of how cool or important a feature is if it is likely to glitch more than 20% of the time you should cut it out of your final product. A smaller, less featured, but smoothly working project is going to win over a more featured but buggy project.
This applies to any kind of live demo in addition to a “go check it out” URL. Don’t demo anything that the judges can’t do themselves when they use the app (unless they don’t get to use the app, in which case you’d better work hard to make sure your demo runs glitch free).
3. Style First, Substance Later
You can ignore this tip if you’re working on a team with a dedicated designer (and how lucky for you if you are), but you should avoid the temptation to dive straight into the depths of coding when you start your project. Instead here are the things that you should do first:
- Create some kind of logo for your project
- Create the best looking landing page you can, even if it takes much longer than you’d like to spend on it
- Create accounts on Twitter, Google Analytics, UserVoice, etc. Anything you’ll want to have at the end create at the beginning
- Buy domains, hosting accounts, etc. and get them all set up how they’ll need to be
Why waste your time on all of these technicalities? Because the landing page is the first impression of your app that any judge will get, and if it doesn’t impress them then you’re already fighting an uphill battle. I spent perhaps the first hour and a half to two hours out of the 24 hour hackathon building the landing page for Qup, but that meant that I wasn’t scrambling to make an ugly slapped-together mess pretty at the last second.
Integrate design and style as you go because when there’s 45 minutes left you’re always going to choose fixing a bug over polishing the interface.
4. Deploy Early, Often, Always
As soon as you have your pretty landing page and logo you should get your production environment up and running. If you can, use a Platform-as-a-Service like Heroku to take the operations burden off of yourself: you’ll have enough to worry about on the app side.
Once you have a working production environment, make sure that you’re deploying and smoke testing your code on a regular basis. There are almost always small (or large) problems that don’t show up locally but do on a production box.
You’ll notice that many of these tips have been about avoiding doing things at the end. That’s because regardless of how carefully you plan you will be scrambling to fix earth-shattering bugs in the final minutes of the competition. It’s tempting to put a tip like “don’t deploy anything in the last two hours” because I’ve been burned multiple times by breaking something big while fixing something little at the last minute, but I won’t. Instead you should be deploying SO FREQUENTLY that any fixes in the last minutes can be rolled back if they are deemed to be a bad idea.
5. In Presentations Show, Don’t Tell, and Stop When You’re Done
Your tech stack and the different ways you tackled the engineering challenges that your project presented are all very interesting. To you. Judges don’t care, judges don’t give a s**t. Instead keep your presentation focused only on the cool things your project does for the end user.
At Hack the Midwest we only had three minutes for presentations. Nearly everyone was running right up against the buzzer, so I was nervous. When it was my turn I gave maybe 20 seconds of exposition and then jumped right into the demo. I showed off my key features, anxious that any second I’d be cut off. In reality I probably still had a minute or more left. But rather than continuing to vamp about how I piped an RSS feed into an API queue fetch pool, I just stopped. I had already made my pitch, and I wouldn’t do anything but hurt my chances from there.
Developers like to believe that code can speak for itself, and that’s actually pretty true. However if your hackathon includes a presentation component you must speak for your code, so don’t completely ignore a plan for presenting.
Do Something YOU Want
One last bonus tip is this: hackathons are about having fun, not winning. I’ve done seven of them and last weekend was the first prize of any kind that I’ve won. The beauty of the hackathon is that it gives you the opportunity to prove your mettle against yourself as much as against anyone else. It lets you say “what can I truly accomplish in X hours?”. For me, this is a powerful drive and one that I’ll gladly challenge myself with again and again. You can expect to see me in most every hackathon that comes around; I’m hooked.
