My Hackathon experience

Introduction:

Hello all! I am penning down my experience participating in a hackathon that I recently participated in in my old office. We have an annual hackathon event that runs for around 30 hours. Previously I have participated in few hackathon events and, I haven't won any prizes before. I didn't bag any prizes this time too. But I had good learning this time and observed few important points to keep in mind while participating in the hackathon as a team.

I am not a person who sits late at night for the hackathon and completes code by burning the midnight oil. My body and mind need rest to think better even if it's for a day or two. I would have contributed only about 5-10% of my work for this hackathon but this time I observed many things apart from code.

Before it vanishes from my mind, let me put down the points for my own self and for people interested in participating in one.

1. It is easy to connect when trying to solve problems faced by oneself.

The problem that we tried to solve is something that can be done easily using Excel. But we tried to create a visual tool that allows uploading data, does data filtering/ grouping/cleaning process with simple drag and drop buttons, and creates a copy of the processed data as an output file. This work is a routine in our day job as we deal with a lot of data. So we can easily connect with the problem that we tried to solve.

2. It doesn't have to be a challenging real-time problem. It can be a simple problem.

The above problem that we tried is very simple. Though it's simple, this tool surely would reduce few minutes of work done in tweaking data for many people in the office, and overall it's a productivity gain. With the above idea in mind and as a team we all agreed on the problem statement that we are trying to solve and started the discussion further

3. Product discussion - Never underestimate this part.

In my previous hackathons, I focussed more on writing code, bringing the system up, and making the API work. I worked as though my sole focus is to run code without getting any errors. No, a hackathon is not about primarily focussing on making code work, trying tech stacks, showing prowess in advanced tech. When people use your product, they are not going to worry about your tech stack. It's more about bringing life to your idea.

Putting down all the requirements for the product to work in a document, take in inputs, data from all the team members, a Team brainstorming session with all points in the document, polish and put down the doable task only, and take ownership (each task to each member or split according to their preference).

This discussion is the core area to focus and having this discussion keeps all the members of the team on the same page as well as helps to collaborate ideas. This discussion doesn't need to revolve more around code, tech stack. It should also include pain points that the tool can solve, basic capabilities, its functionality when working correctly and incorrectly

4. Go with a happy path or least resistant path to build the initial design

Before trying to add checks, error handling, and making the code legible, it's better to start with simple scratch code and make it work and evolve over that. I have failed miserably in my first two hackathons trying to build perfect systems. Let's first solve the problem by taking a happy path without much resistance, get that up and start evolving over it.

5. Use simple tech pieces to build the initial working model

I wouldn't have joined the team where they built the entire data model over the cache system in my early hackathon. But it made a lot of sense to me in my recent hackathon. Having only a day or few hours left, it's ok to bring up the system and show a working proof with a simple tech stack that you know to use well. We had all the data in Redis for my recent hackathon. As it's fast and easy to retrieve, we used this system though RDBMS would make more sense for our use case. It's ok to go with simple tech pieces for quickly seeing our idea into life. Once we got the idea into life, it gave us more motivation to improve on our tech stack. We started to tinker about making our data model better and ended up adding functionality after having a basic working system.

6. Work(4 member team) >> work(1) + work(1) + work(1) + work(1)

I really appreciated the team effort in my recent participation. Energy and expressing ideas in a brainstorming session are contagious. Initially one of them start giving ideas and soon others add and stack ideas on top of it. Making a pitch presentation was also way easier when working as a team. We broke down tasks and worked individually, then we connected virtually and stitched all the tasks together, it came out really well like solving a jigsaw puzzle. We also connected to check the progress of each one's task. We also connected in chat and immediately called out whenever we faced a problem.

7. Cheering up each other.

My recent participation was my first remote hackathon. I really had very less hope to stay active as we are only virtually connected. But we had a soundboard team where even small efforts are appreciated and it felt good to give more contribution. When I was recognized it felt like winning the hackathon and got me to think about all the process happened to make the idea into life. It's then I penned down all these above thoughts on a small sheet of paper after the hackathon.

Thanks for reading :) Share your hackathon experience in the comments.