Earlier this month I did, for the first time in my life, a hackathon and I liked it! The one I did participate in was the Sitecore hackathon 2020. Although I did not expect it, I did learn a lot. What is more surprising, is that I learned more non-technical than technical things.
The hackathon
The Sitecore Hackathon 2020 had the following setup: The organizers would release a couple categories at midnight. From that point in time you had 24h to fully create something in one of the categories. The deliverables should include: A package for installation, an extensive installation manual, documentation and a demo. Each team received a (public) git repo to push your code into.
What I learned
Besides from technical stuff and things about myself, this is what I've learned during this hackathon.
24h is long, very long
24h is a lot of time especially when you are coding almost non-stop. What I noticed is that I needed some breaks, both mental and physical. What I've also noticed that I was tired at the end, so my mood wasn't exactly ecstatic. The last thing I noticed is that the quality of my code lowered at the end. So perhaps it is not a great idea to code non stop for a longer periods of time (or even worse, for multiple days) especially if you need to deliver a high quality, production ready, product.
24h is short, very short
On the other hand, I've also noticed that 24h doesn't give you that much time to deliver something amazing! From the 24h you need to at least extract 2h for testing, writing docs, capturing a demo,.... Then you need to extract at least 2-3h for breaks and eating, since your brain and body do require it. Then you'll also need to remove at least 1h-2h of brainstorming time, since you and the team need to think about what to build. This leaves maximum 17h of time to actually code and that is not much! And before you know it the deadline is there! I think that the same can be said over sprints, although they are between 2 weeks and a month long, you still are timeboxed and you can't work the whole sprint every second of your working day on the product (you still would have meetings, coffee & toilet breaks).
A good mvp is key
In the limited time you have, I've noticed that you need a good basic mvp (e.g. the basic site) as fast as possible so then there is time later on for more advanced, fancy & buzz killing features. This is because a solution with fancy features but that does not have the basics working won't get you there. Don't get me wrong, you need the fancy features to win or at least stand out but your basics should work. Therefor, I believe, the focus should be to deliver a mvp fast to spend the remainder of the time on the fancy features. I also think that a parallel can be drawn to the real world: a good product has fancy stuff but has the basics working!
Build the mvp on expertise
As I explained earlier you need a good working mvp and some great fancy killer features. Because you need the mvp first before the fancy features, you need it ready asap. The best way to do this, is to decide to build it in your field expertise. This means that (almost) no risk is involved and therefor the mvp can be delivered on time. For example, if your team's expertise is building React SPA (single page applications), it would be a great benefit to build the mvp in React as a SPA. Since your team does this all day, it wouldn't take long to deliver something mvp worthy fast and without any risks.
Do risky stuff, but at the end
Then when you have an mvp, you can go wild on the fancy stuff, e.g. machine learning etc. This is a great opportunity to try something new! A great tip would be to not pick up too much and consider the risks of what you're doing (e.g. your skill or knowledge in that field).
Preparation is king
One thing that is almost a necessity is to prepare as much as you can. This means: having all the environments working, have all the tools installed and working, have your git repo up & running,... Also consider the things that are not directly needed for development, but are needed for the hackathon: video capturing software, video editing software, communication tools,... Don't underestimate this, because you don't want to browse around the internet for video capturing software 20 minutes before the deadline. I believe also that here a real-life lesson is hidden: a prepared man is worth two.
Don't spend too much time brainstorming
Although brainstorming and conceptualizing is needed, don't overspend time on this, since you also need to build it. Also when brainstorming take the limited time into account since you won't be able to build everything you want.
Stop developing on time
Don't forget that you possibly need to do other stuff than development (depending on the hackathon). So stop on time with the development work so you can capture a demo, write manuals,... because it takes some time to do that stuff. Also remember by that time, you are almost 24h awake so mistakes will be made & your productivity will be lower. Anticipate this by not starting on those tasks the last hour.
Conclusion
At then end, I can only make one conclusion: Hackathons are a great source of learning! You'll learn about new technologies, software development in general and most importantly yourself!
Top comments (0)