So you want to do a hackathon? Hackathons can be great fun, giving you a chance to compete to build the best product you can in just a couple days. They can help you learn new technologies or platforms and if you’re still a student, gain experience working in a team.
I’ve now taken part in two, Hack the South 2019 and my university’s CampusHack 2020, and while that’s not very many, I thought I would share some things I learnt along the way. Here are my tips to survive a hackathon.
Choosing your project
The first hurdle you’ll have is deciding what to make. Maybe you could make a game, maybe you could make a mobile app or maybe a website. There’s so many possibilities but with such little time to develop, it can be hard to choose a suitable project.
My first tip is to start thinking about this before the event. Coming in with some idea, even just the topic or platform, can go a long way. This can even give you time to pick up any skills you need.
I would also recommend that you don’t worry about whether things have been done before. As long as it hasn’t been done with large success, you should be good to go. That means you shouldn’t worry if you find an old and inactive attempt at it on Github. If your idea really has been tried a lot of times though, perhaps you could modify it or make it more specific to add originality. For example, target it at a specific audience and add specific features they would enjoy.
Whenever I have a good idea, I’m not even excited about it, I get immediately frightened that somebody else has already had that good idea – John Mayer
My third tip is to be careful to not go too far out of your comfort zone. Hackathons are a great chance to learn new things but if you try something too different then you probably won’t get too far. If you don’t care about finishing, go ahead, but if you want something to show for it by the end, you should be careful. In my first hackathon, we developed an Android app and since not many of us had done this before, it didn’t go too well - we gave up and finished with a very buggy app that didn’t really do anything. In my second hackathon, we developed a Slack bot and while we hadn’t done this before either, it wasn’t too different from what we had done and so we did a lot better.
My final tip for this is to start small. Choose an idea that works even if you don’t get very far - an idea that can be very simple or expanded on to be something much bigger. This way, you can give yourself more chance of finishing while still having room to add bells and whistles if you have time.
Getting started
Once you’ve chosen your idea, you need to get started deciding how it’s going to work. What platform suits it best? Who would use it? What’s it for? Think this through but don’t spend too long on the details. Work out what you need for the MVP and leave the rest for later.
Decide what features your product will have in the MVP and at a high level, consider how those could be implemented. If you can, maybe work on a whiteboard that everybody can see, sketching out ideas and listing key points for later. This can be useful to make sure everybody is on the same page and gives a nice way to look back on what was said later.
Once you’ve done this, split tasks up between your team and get going. Depending on the size of the team and the nature of the project, it may be useful to have subteams. In my second hackathon we had a team working on core functionality and another on creating the actual bot and using Flask. This worked really well as we could work on both sides at once, more easily delegate tasks, improve communication and be more confident that we would finish on time.
If you’re going to use a new language for your project, or one that you’re not very familiar with, Learn X in Y minutes can be great for a quick overview of syntax and features. The Github student pack is also good if you’re eligible - this will let you add more collaborators to your repo if it’s private and give you lots of credit and extended trials for software and servies you could need.
Git version control
If you’re going to be working with other people then you need to take advantage of git. Git and Github (or alternatives) mean working on the same codebase together, fixing conflicts easily, reverting changes if needed, tracking ‘issues’ and streamlining your workflow. Make sure you’re working on separate branches and use pull requests to merge these. If you haven’t used git collaboratively before, make sure you familiarise yourself with branching and merging beforehand and feel comfortable using it.
Pair programming
Sometimes it can be helpful to work in pairs, especially if you’re at a point where one person is waiting on another before moving on, or there isn’t enough work left to work individually. This allows you to solve problems together, which is especially useful if you have some difficult part to work on and need to move on quickly. Pair programming can also be fun and can remove the stress of completing certain parts. Moreover, when you’re getting tired, as you inevitably will, this keeps the team going and stops work from slowing to a hault.
Sleep
At some point, you’re going to have to decide whether to sleep. Depending on the team and how everybody like to work, the best decision here can vary. There’s a lot of factors to consider and in the end there’s no right choice. Some things I would consider are
- How far are you from home? Is there somewhere you could sleep at the event?
- How long will it take to get back to work? How long could it take to wake up again and get ready?
- How far are you through the project? Maybe you’re really far behind and feel that powering through will let you catch up, or maybe you think you need the sleep to come back with a fresh pair of eyes. Or maybe you’re lucky enough to be ahead and have plenty of time.
- How many difficulties have you had or are you about to have? Maybe you’ve had a tough time so far and frustration has built up, in which case you might want to sleep. Or maybe you know you’re about to run into some obstacles and think you’ll do better with a little sleep
- Maybe some of you could sleep and others could stay awake? Maybe you could take it in turns?
Presenting
So you’ve got to the end! Well done! Now you just need to present your idea and go home. I suggest you throw together some slides to outline basic aspects and prepare a live demo. Make sure your demo won’t fail and perhaps prepare a video or some screenshots to keep in your slideshow as a backup. During your presentation, keep it engaging and stick to your time limit.
We didn’t stay to present in my first hackathon but in my second we had got a lot further, so we gave it a good shot. I think it went well, we had some nice slides, our demo went smoothly and we even won a challenge from a sponsor, FactSet. I enjoyed showing what we had made and it was great to see what everybody else had been working on as well. If you’re tired then you might just want to go home but I really recommend you stay until the end if you can. You’ve stayed up for this long, what’s another hour or two?
Conclusion
In conclusion, hackathons are a great opportunity to quickly develop a product and have fun along the way. I recommend you plan somewhat beforehand and be realistic when you’re choosing your project. Split tasks well and pair program when needed. Sleep if you need to and give your presentation some thought beforehand. Other than that, have fun and enjoy the free pizza.