Losing a hackathon sucks, but not understanding why sucks even more.
We heard about the Koding Hackathon a few months ago. My colleagues got excited about the idea of spending a weekend to test their limits and bring a product to life so we applied.
Most of us had never been in a hackathon before but were eager to learn new things and work on a cool project. Those with a bit more experience knew that in order to be highly efficient during the event we had to be organised and reserve the two days just for actual work.
So we started having meetings every 3–4 days to discuss about different aspects of what we should build at the hackathon.
First of all we had to know who could actually participate in the event and write code. Checking each person’s availability we realised that we had six people who would be available. Great! that would be more than enough for any MVP.
A hackathon is all about working on an idea that nags you every day, but you don’t have time for… probably because life keeps getting in the way. That’s all good if you work by yourself, but in a team you have to sell everyone on your idea.
We had to make sure everyone enjoyed the experience and that nothing was forced upon them. Above all, our main goal was to learn more about the technologies we set our eyes on lately.
Coming up with a product idea is easier than it looks. For us it took just one meeting to make up a list of 10 ideas we had on the back burner for a while. We settled on a platform for people to get more familiar with building green field applications using microservices. We also built a todo web app that uses a few configurable microservices to show how easy it is to have a scalable, cloud first product in just two days.
In hindsight perhaps we should have set aside more time to iterate on the look and feel. We focused too much on the technology and the value behind the scenes and not enough on how the products looks from a UI and UX perspective.
Either way we got very excited about the product and that’s what really mattered.
In order to finish a complex project in 48 hours you need to be prepared. 90% of the time you spend working on the project should be writing code and 100% of your time you should be having fun.
You don’t have time to make big decisions or research how to work with a new library. This is where your previous experience shines.
In the weeks before the hackathon we spent a lot of time analysing how we could divide the work and break out the application into single responsibility components. We created documentation for each section and defined the interface for each microservice.
That helped us a lot in understanding our product and how all the pieces fit together. It also made it very easy for each developer to focus on his own code and make sure that they follow the interface for their microservice to the letter. That in turn made it very easy to test everything together and we only found minor bugs.
Sadly we forgot to focus on the look and feel of our final product until the second day, so we iterated on that as much as we could, but we could have done a better job at it.
The things that you don’t prepare/plan for usually end of bitting you in the ass. For us this was the deployment part where we didn’t have time to setup an automated process from the start and that caused multiple issues for us, the presentation website for which we focused a lot on the wrong bugs that provided little value for our end user and the third party API we used for sending emails which we were not that familiar with and on which we depended too much on.
Contrary to popular belief a hackathon is not just 24/48 hours of writing code and trying to finish until the deadline. At least not if you want to have any chance at winning. Keep in mind that planning, design and UX are just as important.
We learned a lot about what it means to create a polished product, that performs well on all levels. In the end, I am happy we attended, it was a lot of fun and we grew as fullstack developers.