Last month, The University of Alberta’s Computer Engineering Club held HackED, an annual 24-hour student hackathon. I had a great time volunteering at the event alongside a bunch of DevFactonians, and even had the privilege of judging several great projects to cap off a wonderful weekend.
One of the biggest reasons to participate in a hackathon is not necessarily for the prizes (although there were plenty!), but for the valuable learning experience that the setting of these event offers. So, if you are considering taking part in a hackathon, read on! I’ll be sharing a few helpful tips for anyone preparing themselves for a similar event.
Plan Your Project
In most hackathons, time is the biggest constraint. At HackED, students were given only 24 hours— that’s not a lot of time! While observing several teams, I noticed that the biggest trap participants fall into is picturing the finished product and not planning out how to get there. It might seem counterintuitive to dedicate a lot of time to planning when you’re given a short deadline. However, even 30 minutes spent early in the hackathon means uncovering potential issues before they can surprise you!
Planning a project doesn’t need to be time-consuming, complex, or boring. A planning tool I like to use with teams is a Kanban board. It’s as easy as putting to-do items on sticky notes and then arranging your notes into columns titled “To-do / In Progress / Blocked / Complete”. You can even go one step further and use differently-coloured sticky notes to categorize your work items. When work is being done, write down the name(s) of those who are working on an item. This helps to prevent confusion and also provides a rough gauge of who might be taking on too much/too little work. Lastly, remember that plans can change. If the finished product you were picturing is no longer possible, at least you have an existing plan that can be adapted!
If your hackathon space isn’t conducive to having a physical Kanban board, I recommend Trello to keep it all paperless. It’s free and simple to use, making it perfect for a hackathon!
Ask for Help
Students and industry professionals alike volunteer their time to help you out. It might feel awkward to have to pipe up and flag somebody down, but trust me, it’s worth it. At work, I’ve had moments where a 5-minute conversation solved a coding problem that I had spent hours trying to crack by myself. At HackED, we have mentors with web, mobile, 3D, embedded, and hardware experience. If we don’t know the answer, we can find somebody who does.
Take Regular(-ish) Breaks
Developers are an interesting breed: we need extended periods of undistracted time to solve tough problems, but we also need time to decompress. When starting your project, decide on when the team should take breaks (for lunch, for snacks, or simply to relax) and give your minds a rest. Set a rule to not even talk about the project while you’re taking your break. As unintuitive as it may sound (the clock is running!), your mind needs a break too. For those who need to be told when to take breaks, the Pomodoro Technique may be helpful.
Sleep (Yes, sleep!)
I get it, 24 hours is not a lot of time. But then again neglecting sleep is probably going to hurt your project. Some teams that I assisted ran into problems caused by late-night coding. They patched issues with hack after hack, eventually causing a big mess that became hard to fix. Plan that the whole team (no late-night warriors allowed!) gets at least 6 hours of sleep (either on-premises or elsewhere) and re-convenes in the morning, recharged and motivated to finish the project. Lucky for us, breakfast was provided at HackED making hackathon Sunday a little less stressful.
Rehearse Your Demo
Judging can be subjective, but all judges appreciate a well-prepared demo. Some teams straight up admit they are at the hackathon for the learning experience rather than for building a demonstrable product, and that’s ok! So as long as the presenters knew what they wanted to say, us judges appreciated the gesture.
For teams that have something they want to demonstrate, it’s useful to describe what your project was about, and what each person did. From there, demonstrate key areas of your project and leave time for questions. I recommend leaving the last 30-45 minutes of your hackathon to identifying what you’d like to demonstrate, and then rehearsing the demo at least a couple times. Remember that a hackathon is a learning environment, so even if you’re not a strong presenter just yet, you can use it to practice your presenting skills as well.
Don’t Forget to Show Up
The last, and most important piece of advice, is to just attend the hackathon, even if you don’t have or don’t feel like you’re ready. As someone who graduated from the University of Alberta not that long ago, I do regret that I never took part in hackathons when I was an undergrad. The excitement in the air at the beginning, the antics that happen as the night wears on, and the intensity of the final hours are just some things you have to experience at least once in your student life.
I hope that these tips will help you get the most out of your next hackathon experience!
Big thanks to the U of A Computer Engineering Club for the opportunity to take part in the 2019 HackEd hackathon and for providing photos from the event.