Hackathon Takeaways
Notes for anyone who wants to go for a hackathon (and for my future reference…):
1. Preparation Get used to your tools. Eg. if using an API you have never used before, get familiar with it before going for the hackathon. You don’t want to be wasting time trying to figure out how to do a for-loop or resize pictures. Generally, hackathons state that you cannot start work before the day of the hackathon itself, but there doesn’t seem to be a rule saying how much preparation you can actually do. My interpretation is that as long as you do not put the stack together, you should be fine.
2. Planning At least have a rough idea of what to do and who is going to do what. If not, someone is going to end up doing all the work. It’s fine to not have a leader; more importantly, get a team you can work well with. With the rushed pace of a hackathon, lack of sleep, caffeine-induced adrenaline rush and a deadline looming, tensions are bound to rise.
3. Don’t overestimate Don’t overestimate your abilities. If you need help, ask for it. Don’t try to claim all the tasks for yourself, that’s why there’s a team! Also, split the tasks into smaller portions so that it is easier to estimate how much time each task will take.
4. Communication Set up proper communication channels. Essentially, a channel for code version-control (eg. git), discussions, passing around of documents. Even better if the last two are combined. Frustration usually arises from mis-communications or a failure of the whole team understanding what they are working towards. Don’t be afraid to draw diagrams even if they aren’t standard/what you learnt in school (no one can remember those confusing UML diagrams); pictures speak a thousand words, diagrams probably more.
5. Have fun It’s a hackathon come on!
Reference: ksami, 2-time participant and fail-to-submit-er of Hack&Roll