FlightAware's yearly hackathons are a fun diversion from usual work where we can focus on just making something cool. They're also an opportunity to vie for dominance on the battlefield of public opinion! Coolest project wins.

I've always loved hackathons. It started in college, where a hackathon was just a good excuse to stay up all night with your friends drinking red bull, fooling around, and getting free swag. Maybe you coded up something impressive by the end, but your brain was probably too fried from sleep deprivation to care either way.

I was delighted, then, to discover when joining FlightAware that they also host a yearly employee hackathon. The 24-hour timeline is swapped for around 2 working days of hacking, but the spirit of the hackathon is still surprisingly consistent with what I remember from school: just build something cool. It doesn't need to be FlightAware's next big idea, it doesn't need any product potential, and it definitely doesn't need any tests or documentation.

At the end of each FlightAware hackathon, the teams present their projects to the rest of the company and then the participants vote on who had the best project (no voting for yourself of course). There's no real rubric for voting; people just pick the project they liked the most. The team receiving the most votes are crowned the winners and get bragging rights for the rest of the year.

I've had the good fortune of being on the winning team for the last few years and would like to share some tips I've developed over those years for how to take your hackathon game to the next level. I'll also be sharing some anecdotes from past projects to highlight the effectiveness of my strategy (I hope you'll see this more as a nostalgic trip down memory lane and less like brazen gloating).

The presentation matters as much as the code

I get it, we're engineers, we like to code. We don't so much like putting together and rehearsing PowerPoint presentations. "Isn't the point of a hackathon to hack?", you ask. Well, yes, but ultimately you're here because you want to win, right? If so, you're going to need to spend more than 15 or 20 minutes on creating the presentation. All your hard work will have gone to waste if you don't tell people about it.

For a technical analogy: think of the presentation like an interface, and your project as the implementation. No one's ever going to look at your awful hacked-together code, just as far fewer people work with a module's implementation versus its interface.

For a team that faced serious roadblocks, this is also your chance to tell your story. Share the approaches you tried that didn't work out (make sure to include silly screenshots if you've got them).

Be sure to also involve all team members in the presentation, with everyone getting a chance to speak, and rehearse it all the way through at least once.

The demo is the most important part of the presentation

Steve Jobs knew the value of a good live demo. As much as your presentation matters, the only thing people are probably going to remember from it is your demo. It directly answers the question: did you accomplish what you set out to do?

I use demo-ability as my guiding light when brainstorming hackathon projects. Having a good demo in mind can really give a project focus. I can always feel the excitement in the team build as step-by-step we get closer to something that really works. Picking a project, working on it for a couple days, and then scrambling to figure out how you're going to show it off right at the end isn't a recipe for victory.

Your demo should be carefully rehearsed. Don't just pick some random examples and cross your fingers, pick examples that show your project at its best! You likely missed plenty of edge cases when working on it; the worst time for those to rear their heads is during the demo. You don't want to be too misleading, but I think it's totally fine to tune your project to the specific use cases you want to show off.

Try to ensure your demo is memorable and stays on people's minds. One possibly risky approach could be to share a link to your project with your audience so they can engage and play with it themselves. This is particularly effective at FlightAware now that we're fully remote, meaning most people are watching the hackathon presentations at their computers. This does risk spoiling your careful rehearsing, though, and may readily show the cracks in your project.

The "crowd participation" approach didn't quite go to plan for my team's demo in 2021. Our project involved revamping FlightAware's internal "quip" system. Quips are how we keep track of the funny, embarrassing, or bitingly sarcastic things our colleagues have said that deserve to be memorialized (we have a corner of our operational dashboards dedicated to rotating through random quips). Previously, this was handled by an extremely barebones HTML form for submitting and a table for viewing. We thought it'd be fun to integrate quip submission more closely with Slack, as that's where most of them came from anyway. We introduced the ability to "quip" a message by reacting to it with a specific emoji. People quickly found the limits of this new quipping ability during our demo (reacting to bots, pictures, etc), and we had to do some brief live debugging to get things working again.

Another option is to inject some whimsy or humor into your demo. In 2022, my team worked on a project we called SongBird. It used the Spotify API to play music on www.flightaware.com flight pages based on the aircraft's location. We had various ideas for our musical choices when the plane was over land: artists born nearby, songs that mention the state in their title, etc, but we struggled with what to play for planes over oceans. We could have tuned our demo to avoid such a case, but instead we opted for an easter egg where oceanic flights would play Never Gonna Give You Up and Rickrolled the audience by demoing such a flight.

Demo-driven development

Treating the demo as your deliverable rather than your code can be quite freeing! Cleanliness, tests, documentation, none of it matters in the face of creating something that has to work for just a few specific cases. In fact, they all drain precious time.

Do you need to expose a service on a local machine? Don't waste your time fiddling with firewalls, just sprinkle some ngrok on it. Does your app have a huge memory leak and crashes after 20 minutes? No problem, just restart it right before the demo.

Thinking back to the SongBird project I mentioned above: Spotify uses OAuth2.0 to control access to its API. The access token that Spotify generates as part of that flow is only valid for 1 hour, at which point you're expected to get a new one using a refresh token. OAuth2.0 is pretty much the last thing anyone wants to be thinking about when they've got 2 days to make something worth showing off. Instead, we just manually regenerated the access token as needed when it expired (and made sure to regenerate it right before the demo, just in case).

Conclusion

Much of this post was a bit tongue-in-cheek. The main focus of a hackathon should be about having fun, building cool stuff, and rekindling that startup spirit of moving fast and breaking things. Winning an ill-defined popularity contest is just a small cherry on top. In the end, it's hard to say whether 3 wins in a row is a fluke or if I've really got hackathons figured out now. After 4 wins, though; then I'll know for sure.