What I Learned from 3 Hackathons in 3 months
My personal reflection on participating in 3 back-to-back hackathons for 3 months
Hackathons are amazing events where developers, designers and thinkers can come together to build an awesome prototype product within a specified time period. If you're familiar with this blog, you probably know that I like to participate in hackathons and then write about my experiences here.
Feel free to check out my Hackathons Series to read more about them.
Hello everyone, in this article, I want to share my learnings and how I managed to participate in 3 hackathons in a row without stopping for 3 months (June-September). At the end of this article, I have answered some FAQs that some of my readers have asked me about hackathons.
1. Project/Time Management
The more time we have until the deadline, the more we think we have more time to complete something. This is a famous adage known as the Parkinson’s Law. I experienced it first-hand when I observed the amount of time I put in the hackathons depends on the duration of the hackathon.
Read more about the Parkinson's Law here.
In the 48-hour hackathon, I allocated a huge chunk of time to concentrate on the project and therefore, procrastinate less. The prototype was completed early, and my team was super elated to win! Read about the experience here.
On the other hand, for the 2-week and the 8-week hackathons, I thought I paced myself well but looking back, ended up procrastinating a lot. We created a Discord server to communicate but as seen in the screenshot below, we added an insane amount of random channels and procrastinated so much in the first weeks.
When the deadline was near, only then my team and I started to work hard to complete on time. This is the Parkinson's Law at work, where increasingly complex work relatively induce procrastination according to the amount of time available.
Going non-stop in 3 hackathons, I learned that productivity is like running a marathon, you can't sprint too fast, and you can't saunter either. You need to know how much you can do per day and set milestones.
To overcome the effects of Parkinson's Law, my team use a simple app like Todoist to allocate and assign our tickets. But because there were no milestones set, it was easy to get sidetracked. We slowly figured out that the best way is to set up weekly meetings to discuss our milestones and ensure everyone stays on the same page.
Most hackathons will require teams to submit a product, which means rapid prototyping is an essential skill and something I definitely picked up over the course of 3 back-to-back hackathons.
Figma is an incredible tool for rapid prototyping. Not only does it help understand the app idea from the user's perspective, it also communicates the idea among team members.
I find that it also helps the developers in the team to focus on functionality over visuals first, as the designers can take care of that. By sketching the overall architecture of the idea, it also becomes much easier to streamline the process for both the design and development team.
By the 3rd hackathon, I have learned rapid prototyping and design thinking principles to identify needs, pain points and how to design a product around it with a team.
3. Knowing the Limits
For longer hackathons, it is important to understand that team members have other commitments. The same goes for me, as I have an article to publish on my blog every week.
When I participated in these hackathons, I found myself spending so much time on the hackathon that I could hardly manage my weekly blog schedule. My blog draft count has shrunken considerably, since these 3 hackathons are non-stop for the period from June to September.
As a result, I postponed or declined many social activities because of hackathons. It snowballed into reduced sleep hours/quality and poorer lifestyle habits. Despite that, I think I managed my time pretty well and in the process, I learned to understand my team member have commitments too and assign fair work for them.
Because time is a limited resource, I tried to be flexible by allocating and re-allocating deadlines according to my team members' time available.
As the leader, I tried to set clear expectations and be realistic about them because sometimes, it is not possible to have a fully polished app ready. I would rather have a decent prototype completed than having a very polished app but with our team members getting burnout, because I pushed them over their limits.
This can break down team morale, and so I learned to pay attention to my team member's condition. I asked myself these questions to understand their limits:
- Do they have other commitments?
- Does a member's task depends on another team member's task?
- How soon will they be able to finish without too much pressure?
And ultimately, this helped me to give those who want space, space. And give those who want time, time.
4. Foster Good Communication
Every hackathon team is like a small and elite project team at work. When we talk about the project, we stay professional, even among friends. We follow good communication practices, respect different opinions in coding style, art style, work style, etc.
For longer hackathons, we schedule weekly progress updates. Even if a team member is struggling to keep up with deadlines, we encourage each other and agreed that no one should blame anyone.
In many cases, your hackathon team members are initially strangers to you. So I tried to talk about random things besides the project because it is easier to work with people you like, and it helps build team rapport.
Of course, while having these random conversations are great for team bonding, we can sometimes get too carried away that nothing gets done. In the beginning, I was not a very responsible leader (I have to admit) and so these hackathons taught me to stay disciplined and keep everyone motivated till the very last day.
Frankly, it was a long and tough experience to be doing these hackathons without rest. But the rewards of learning and meeting new friends makes this an unforgettable and meaningful personal growth experience in 2021.
I remembered September 5, that was the day my long 3-months of back-to-back hackathon marathon ended. That day, I submitted our work as team leader, did all the admin-related requirements and went straight to bed. It was 2pm. I woke up 6pm, ate dinner then went to bed again at 8pm. I never slept more than 5 hours in 3 months and it felt so great.
Hackathons are truly inspiring experiences and if you have never participated in hackathons before, I highly encourage you to try. There are many virtual hackathons around and I like to check out devpost.com to browse upcoming ones. Also, please feel free to read the FAQs section below from questions asked by fellow readers.
Thank you for reading this rather personal and long article. I'd like to conclude this article by thanking every team member that I worked with in these 3 hackathons. They are dedicated, passionate and amazing individuals who I am sure will rise to new heights in their respective industries. Cheers!
Special thanks to:
1. Do you get burnout from participating in hackathons?
Yes sometimes, but it is not because of the hackathon itself. It is because of me not finding the right balance to incorporate it into my routine. I feel that my burnouts are more prominent in longer hackathons, as I have to be consistent in making time for it in my routine while not neglecting other commitments for a longer period of time.
In hackathons, burnouts can happen when you realized that you're doing most of the work and not getting enough sleep. Hence, it is important to communicate to your team if you're starting to feel burnout. Ask the team leader to re-allocate tasks or re-assign deadlines to make sure your burnout is reduced.
If you're participating solo, make sure you have enough sleep and eat well. This is very important to keep a healthy level of energy and mental state as you progress in the hackathon.
2. For hackathon newbies, what factors should I consider when choosing a hackathon to participate in?
Personally, I think duration is important. Knowing how long you need to commit and asking yourself if you can commit for this amount of time is important.
Second is the theme. Is it a game hackathon, machine learning hackathon or mobile app hackathon? What kind of technologies are you required to use? What are the deliverables? It is better to stick with a hackathon that has a theme you're passionate about. It can keep you motivated from the start.
Then, other factors such as the hackathon's location/timezone, the type of people you will form teams with, etc. will all come into mind. Decide if you want to go solo or in a team. In my opinion, I prefer working with teams, as I always learn more with others than working by myself.
3. I'm a shy person... How do I find good and reliable teammates in hackathons?
Try to meet and find team members that you think will work well with you. Reach out and ask questions about their background in tech or their motivation for joining the hackathon.
Not all team members have to be programmers. This usually depends on the goal of the hackathon. If the objective is to build a complete app, then you can think about having more programmers in your team. Else, if the goal is a simple prototype and the idea presentation or the concept design matters more, then aim to diversify to get inspired from different perspectives. I have met designers, entrepreneurs and marketers in hackathons before. They can all bring something of value to the table when building and designing a prototype.