My First Hackathon

Last month I participated in my first Hackathon, a programming/tinkering competition that lasts 24 continuous hours. It was promoted and executed at my current company, Senior Sistemas.

The competition’s scope was Smart Cities, compressing the topics urban mobility, public health and public accounts management. From these topics the solution devised by my team was an app to show people where the parking spaces at the city are, including private and public parking spaces. We came up with this solution because the traffic here at Blumenau is just awful, and such an app would certainly improve the overall traffic quality.

From this (exhausting) experience I took some points that’d certainly help me if I ever participated in another such endeavor, and also some that just helped me grow as a person and a developer.

Pick the right team

I cannot stress enough the importance of picking the right people for your team. Without the right team, all the other topics would be a lot harder to accomplish, but with the right one you can arrive totally unprepared for the competition and something good would still come out of it.

I was lucky enough to end up with the right people, namely Guilherme, Adriana and Marcelo. These are excited people that made the overall experience quite pleasant.

Prepare beforehand

One thing that became clear at the first two hours of the competition was how prepared and at the same time unprepared we were for it. I’ll explain:

One week before the first day of competition we were presented with the general topic, which was smart cities. But we were also told that the specific, and therefore valid, topics would only be told at the day of the competition. So, while we could devise lots of possible solutions, implementing them would be a waste of time. This is the part where we proved to be prepared: we devised many possible solutions, to be implemented only at the competition, thinking about the pros and cons of each, how they would help the city and how difficult it would be to setup them in a real environment.

At the opposite spectrum, we weren’t quite prepared because we didn’t create an attack plan for the competition. We didn’t devise how we’d implement the solution, its architecture and components, and who would be responsible for each component.

So, my take away from this is: brainstorm lots of possible solutions, pick some of the best (preferably one for each possible topic of the competition) and structure how the solution can be implemented.

Allocate the work

Ten hours or so into the competition I was left with little work to do and was just helping my colleagues out. Yes, I was still being helpful, but not as much as I could’ve had the workload been better allocated. There were three components in our solution: a mobile app, a web page, and the server backend. At some point, the backend part started to collide with the web page, the latter being my responsibility, and so we decided that the web page and the backend should actually compose a single component.

Summing up: put some real effort in the first couple of hours of the competition into architecting the solution and allocating the work among the team members.

Try to have some fun

Because if you go into the competition to get stressed and tired, chances are you won’t be keen to participate in another one so soon. And that’d be a shame, right?!

Feel accomplished

One thing that I feel we’ve nailed at the competition was to accomplish a working version of the proposed solution. Yes, there were some functionalities missing, but the final product was usable and useful. And accomplishing that made me feel much more confident for a possible next competition. It was a huge confidence boost!

Rinse and repeat

Truth be told, after 24 hours of non-stop competition, I left promising myself to never do something like that again. But that’s just a temporary feeling. After getting some proper rest and weighting the pros and cons I would totally participate in another Hackathon.