Hint: It’s Not Coding
This weekend, I attended my first Hackathon.
Hackathon? Yep, hacking + marathon.
Basically, a hackathon is a competition where groups of people are formed to come up with a problem, an idea (i.e. a solution for that problem) and then try to realize a code-based (hence: hacking) solution. This all goes down in a predefined and very limited time frame (few hours — few days) with often very little to no sleep for the competitors (hence: marathon).In the end, a winning team is chosen by a jury and given a reward.
For me, there was one caveat though: I can’t program.
But, this specific event also explicitly allowed non-coders to participate. Lucky me.
I could tell you a whole story about the night of non-stop working (we had 24h and made use of most of it) and the amount of pizza, Red Bull and coffee it involved, but I thought I would instead list the 3 most important skills I learned during this day (and night).
0. Not programming
Even though there were times my team would’ve appreciated an extra coder, 24 hours is just too little time to get into programming deep enough to be able to contribute in any meaningful way.Besides that, people are there to program, not to teach programming.
1. An idea is only worth as much as it’s implementation
You can fantasize all day about what else your program or app could and should do. Fact of the matter is though, all these add-ons take real time to implement. And even though the time limit is extreme for an event like this, that fact is still true in real life for any real life problem you would like to solve. Time is a limited resource.
In the end, what counts is the product you can show and present, not the product you envisioned in your mind.
2. Prioritizing is the number one priority
Based on time being limited, you first have to decide what things to actually work on and what ideas to save for later. In other words: you have to get your priorities straight.What’s your MVP (minimum viable product)?What does your app or program have to do?And, very importantly, what add-ons sound kinda cool but are not a core necessity for your solution?
3. Don’t get attached to any of your previous decisions
I want to explain this on a problem our group encountered: We decided at the start that we want to program using a drag-and-drop software tool (Node-RED), because this allowed the non-coders of us to also get into it as it’s very intuitive.But as we got more into it and got to know it better, we also encountered more and more problems.In the end, we made the decision to switch programming language at 3 a.m. at night and basically had to start all over again halfway through the competition.Now, we could’ve been stubborn and kept on trying to make Node-RED work (and btw, we had already made quite some progress with it), but even though we “lost” time by pivoting halfway, I think it was the most important AND best decision we made.