Hackathons – Impacting People, Organizations and Technology

Over the past few years, I’ve been fortunate enough to take part in a few hackathons and to experience the event taking different roles in it. 

Being an organizer

My hackathon journey started in my second year in university when along with several like-minded colleagues we decided to take on the challenge of organizing the event. At the very beginning we were very far away from having an exact plan what and how we want to achieve yet again we were hooked on the idea. We slowly started dividing the enormous endeavor into smaller, more manageable and tangible tasks. As cliché as it sounds, it was a learning experience for all of us.

Conversely, what I now realize to my surprise is how much freedom to be creative we had as organizers. We had to take numerous decisions ranging from who do we want our target audience to be, how do we imagine reaching them, what do we want to be the atmosphere and topic of the hackathon and so much more. Compared to how much time a participating team has at their hands to develop their idea in the event, it feels like we as organizers had the whole time in the world to discuss, collaborate, gather information and advice before taking the important final decisions. Of course, it was not all sunshine and roses – there were a lot of internal disagreements, misunderstandings and miscommunication at times. Dealing with all these internal issues is probably the number one experience that helped us grow as a team. Organizing the event left an impact on everyone.

The months of preparation filled with overthinking crazy ideas, working with self-assigned deadlines, sleepless nights and many other ups and downs finally paid off. The hackathon gathered high school and university students from the city and the greater region. Some of them arrived already in a group as team, some other assembled spontaneously. At times I felt the atmosphere in the hall as magic, at other times I felt it as an orderly mess. Looking at it from the time distance now, I appreciate the greater, mostly unpredictable, impact of the hackathon. The orderly mess that lasted for about 2 days was an environment in which MVP solutions were built and scratched over several times, long-lasting friendships came to being, mentors found their apprentices and many other events of their own happened. As organizers we had to spend so much thought on planning out for the hackathon, yet the magic of the event lies in every unpredictable moment that happens during it.

With the lessons learned from the first hackathon we organized another one months later. This time around we were focused on improving the event instead of building it from the ground up. This second edition of the hackathon felt as madness once again albeit a refined madness in my eyes. It took a few more years for me to switch places and get on the participating end of things.

Being a Participant

In the span of just a few months there were 2 internal hackathons organized in Documaster. The idea behind both was to focus and work on technologically centered ideas for improving our components. While the overall premise of the company hackathons felt distant to the ones we used to organize at university, the atmosphere was not at all that far off.

We had less than 48 hours to work on a proof-of-concept solutions and present them in front of the whole office in Bulgaria. Most of the ideas worked upon were topics of discussion for months, but the time was never right for someone to start the research and development on them. That was the most significant reason why so many of us could not wait for the event. Some of the ideas concerned optimizing our development flow and internal tooling, some were about new user-facing features, some other were about introducing new types of testing for the product.

I personally worked on the matter of “dockerizing” our major components for the first hackathon with one other colleague. At first, we were optimistic about the scale of the task given the time for the hackathon. We already had some docker configurations that ran monolithically so our main task was to split that up rather than develop things from complete scratch. Of course, once the actual development started, we did hit many issues along the way – we had to come up with a technique for the components to properly await each other in the final starting phase, we had to resolve VPN issues and decide on what’s the right default state for the components so they can be utilized by as many people as possible. While the task wasn’t finished in time for the hackathon finale, it encouraged us to continue working on it throughout the coming weeks. 

At the end of the company hackathons every team was a winner – everybody developed something exciting for them, brought some value and a positive impact to the organization and possibly the end clients. Other hackathons, however, must select their official winning teams who had managed to persuade the jury in the excellence of their execution, idea, implementation and presentation.

Being a Jury Member

I was invited to be part of the jury for the latest edition of the hackathon that started it all, it was time for HackAUBG 4.0. It’s the position with the shortest lifespan – just a few hours. It’s also the position with the most well-defined responsibilities - there’s little space to do anything out of line. Yet again it is a challenge for which you can and should prepare. The way I tackled it was by asking for advice one of the experienced members of the jury from the previous editions of HackAUBG. His number one advice was to take detailed notes during the presentations. Equipped with them I was able to bring up valid points for defending the teams I sided with in front of the other jury members.

Besides personal notetaking, it was crucial that we as a jury worked as a cohesive team during the Q&A minutes of the presentation slots. Fortunately for us, the organizing team brought us together well beforehand to give us the time to agree on some basic rulesets. It helped us clear out the way we would sync effectively in real time when it was our turn to ask questions to the teams – our most significant job that should be executed with as few hiccups as possible.

The major criteria on which we graded the teams’ accomplishments were the complexity of their solutions, the degree to which they were developed during the event, the originality of their ideas and their presentation performance. These general categories were further divided into smaller subtopics for assessment which helped me with the judging process. The greatest challenge while evaluating the presentations was the constant need to multitask between thinking about it and remaining present in the auditorium, listening to what’s happening.

After announcing the winning teams and the hackathon officially came to its end I was put on the other side of the fence. Almost every team was eager to hear some feedback on its performance, they asked questions about the areas they needed to improve, what we did not approve of as jury and so on. One more occasion on which the detailed notetaking came in handy.

While this was my first and only experience in the shoes of a jury member, what made the hackathon count for me was the simple realization of seeing all the passionate organizers, participants, mentors and partners in the same place years after the event was originally born.

No matter what role you come to play in a hackathon you are bound to be involved in an adventure full of exchanging ideas, building up human relationships, applying and learning more about cutting-edge technology, arriving at unexpected results.