Last week, I took some time off to join an internal hackathon at work. Nothing comes close to the thrill of going from zero to one in a short time—starting with an idea, executing it, getting stuck, pivoting, and then finally shipping it!
Over the years, participating in and organizing hackathons, I have learned the approach of building software quickly is very different than building good software. I wanted to distill my thoughts primarily for myself and for any teammate in a future hackathon. If it helps anyone else, that would be a bonus!
Start with the End in Mind
Most hackathons end with the teams doing a demo of their implementation. This demo is either done in front of a live audience or submitted as a pre-recorded video. It is the sole medium of communicating the potential of the idea and the product to the hackathon judges. The guiding principle for every decision throughout the hackathon should be this:
What will make the demo an effective communicator of the product's value?
The Team
If you are thrown into a team of unknowns, that’s probably a difficult scenario. Building software is a team sport, and knowing who plays well in which position is the ultimate advantage. Go with your own team if you can.
Dividing work is possibly the most difficult part of the hackathon, and bigger teams make it harder. For a two-day hackathon, a team size of three seems to be ideal; four is the maximum. Beyond that, the speed of communication and integration issues become a major hindrance. The trick to combat this is to use techniques like pair programming or mob programming. It reduces decisions made in isolation. By round-robin the active tasking among the pair working together, you can keep engagement high and reduce the cognitive burden.
Keeping it Simple
Think from the perspective of a judge. If they are reviewing 20 to 30 submissions and can spare about 5 minutes or less looking at your submission, what would make a demo stand out? If your hackathon has more than one theme and you are picking a crowded one, realize that your idea and execution will face more competition.
Aligning with the theme of your hackathon is obviously important, but do not feel limited—creatively add, subtract, bundle, or unbundle ideas. If you have too many ideas or features to choose from, ask how the user (judge) will feel or be impacted if they can no longer use your product or feature (Sean Ellis score). Write the ideas on stickies, put them in a Venn diagram of feasible and valuable. Pick the one in the intersection that minimizes time for feasibility and maximizes the impact on the user.
Code Freeze
The Tech Stack
Often hackathons are marketing events organized by a company to showcase their product’s new feature. Even if that’s not the type of hackathon you are at, it would be rare to have zero unknowns in the technology stack that will emerge as blockers. A bug in the tool, your unfamiliarity with the technology, or something completely unexpected is going to happen. To mitigate that risk, you need to reduce the known unknowns. Pick your tools based on what you know, what the app needs, and what you’ll have to learn along the way—in that order.
The Hack
Finally, the most fun part—writing code. Even before the advent of AI for generating code, there were libraries and frameworks that you could leverage to do a lot of heavy lifting. Today, AI is definitely an accelerator for understanding and writing individual modules. However, what remains unchanged is putting the effort of different pieces together. Integration is the most critical and vulnerable part of hacking together multiple components within a short time frame.
As I said in the beginning, a hackathon is the time for building software fast, rather than building robust software. So it is okay to hardcode values and stub out function calls. But you have to bear the cognitive load all along the way on how those shortcuts finally impact the demo. The shortcuts might seem easy to remember in the first few hours, but as the tech debt grows, keeping track of them becomes the real challenge.
Regular Check-ins
Internal communication is the best defense against this brittleness. Your teammates need to know if one of the fields is hardcoded, passing different values in the API call will not change the value in the results. This is why you need to have regular short check-ins with the team. Set a deadline for the next check-in at the end of one. Have a shared visual board of who is working on what, with swim lanes of To-Do, Doing, Blocked, and Done. Having a list of tech debts might not be a bad idea. As a team, reevaluate and reprioritize your task list.
Knowing When to Pivot
You’ll know. The sooner, the better. Ego is the Enemy. If something is not working, that is not a character judgment. Getting stuck and refusing to move on, however, could provoke one. Feel free to ask for help; trying to explain the problem sometimes reveals the solution. Finding another hack when things are not working is what this is all about.
Get Some Rest
Sneak in some rest from time to time. It is important to give your body and mind a break. Stretch out, stay hydrated, avoid too much sugar or energy drinks. Walk around to say hello to the other teams.
Demo
Finally, show your work – bring out the salesman. Show your work. Communicate the value. And then breathe a sigh of relief that its done!
Despite all the steps above, things will go wrong. Brittle software has a bad habit of hiding bugs until the prime time. So your demo might fail majestically, you might forget the lines that you rehearsed, or your delivery might not be the best. You’ll have a cringy hangover of your failed demo, but trust me, that is okay. It is not the end of the world, it is not your last hackathon. Every hackathon is an opportunity to learn much more than just technology. It is project planning, team building, product management—but above all, having fun! That’s the only strategy that works!
P.S.
1. Thanks to Sayan for his input!
2. Going to post it on hackernews, to learn what hackathon veterans have to share from their experiences in the discussions.