Hackathons: The recipe for success

Hackathons are all about problem solving under pressure. They require a focused plan, a dedicated team and plenty of time for things to go wrong.

The goal of a hackathon is to achieve a specific, often ambitious, target within a tight deadline; not to perfect a final product but to prototype a solution.

The “hack” in hackathon is the key difference compared to regular coding. It means to have a quick fix or band aid solution. It’s not about writing the cleanest, most readable code but more about hacking a solution together as quickly as possible. The point here is that the tools used are not as important as the process and I think the following parts of the process are what make a hackathon successful:

Planning

Mike Tyson once said “Everyone has a plan until they get punched in the mouth” and you can expect when the time comes, the hackathon will punch you in the mouth. But does that mean there’s no point in planning? Not at all. Having a plan before the event starts means there is more allowance for things to go wrong.

Going into this hackathon, my team made sure we knew the foundations of what we were going to build. This covered the kind of game we were building, how many players we were going to accommodate, what tech stack we were going to use, what our Minimum Viable Product (MVP) was and when we expected to achieve it. This way when changes needed to be made, we were able to pivot as needed around our plan.

We also made sure to estimate how long we thought it would take to reach our MVP and gave ourselves a couple of hours of buffer time for things to go wrong, which they did.

Teamwork

Teamwork is one of those obvious ones. You might be thinking to yourself “Yes I know I need to work well with others” but what I’m talking about is specific strategies that help keep the train on the tracks. The things that I found important were ensuring everyone had a clear idea of the MVP and their individual tasks. We spent a good chunk of time on the first day just writing up tickets and assigning them.

The key here was to not stray outside of the bounds of that task as this could have unforeseen issues when different parts of the code come together. This is pretty basic team etiquette but when you’ve only got an hour until presentations and you’ve got to merge two completely different features together, it can be pretty stressful.

The last, and arguably most important thing is to be able to have a laugh with your teammates. At the end of the day no one is going to die if you can’t quite get the product to where you want it so you might as well have some fun along the way.

Ego

When doing something creative, I find it’s very easy to let my ideas get in the way of what’s best for the product (and the people involved!). This is where I've needed to be aware of how much my ego is influencing my decision making. It’s also important in such a pressure cooker environment to recognise when a mistake is made and let the team know as soon as possible.

The last and most critical part of the dance with ego is accepting that failure is part of the process. The point of a hackathon is pushing yourself into an area that you are not comfortable with and that means there's a good chance it won’t go as planned.

What a successful hackathon really boils down to is finding ways to make it easier to enjoy the process. Hopefully it’s satisfying to see the goal come to life but the learning that comes out of the process is the real joy.

Here’s a screen grab of the finished result:

Thank you to freeCodeCamp for starting us out with this tutorial and Open Game Art for providing some of the assets!