Lessons learned from the Global Hack 2020
Hackathons are a great place to see fantastic ideas born, build your social and professional networks, and get new laptop stickers.
To solve some of the problems created by the immediate crisis, I joined the Global Hack. The team I was in worked on building a system that connects people in need of assistance to a network of volunteers, mostly aimed towards helping the elderly and quarantined.In this post I would like to share my experience and what I have learned from that event.
Why hack?
I think everyone who has ever attended a hackathon has a love-hate relationship with them. On one hand, it’s very satisfying to down 2l cans of Coke Zero, miss a night or two of sleep, and get some semblance of a project out on a weekend. On the other hand, weekends are for resting and hackathons are stressful by nature. Either way, it’s a great place to see fantastic ideas born, build your social and professional networks, and get new laptop stickers.
In the times of self-imposed quarantine, of course, it’s frowned upon to get 100 people together in a small room, so hackathons have adjusted to the new reality. Last month, Hack The Crisis kickstarted a huge international community of remote, online-only hackathons. Now there are many events organised on both a local and global scale, the biggest so far being this past weekend’s The Global Hack – it was attended by over 15,000 people worldwide, resulting in more than 500 projects. And it had Erykah Badu at the after-party.
When an acquaintance of mine posted on Facebook that they need some front-end development help on the Global Hack, I gladly volunteered. Just in case, I also recruited some of my Proekspert colleagues (the more, the merrier)! And less work, or at least so I thought.
Lesson 1: process organization
Hackathons are often devoid of structure. You describe the idea, quickly identify what part you could help with, and then go do it until you run into problems. This kind of informal and rapidly shifting collaboration is easy face-to-face, but when you’re all online, it’s hard to see who’s doing what.
To remedy the situation I proposed that we list issues on Github and allow people to assign themselves to them. This would give us an overview of what’s being done and who’s dealing with it. I think it worked well and would recommend it for future hackathons. No need to define these issues in a formal manner, just quickly jot down what needs doing and slap some labels on it – what should be prioritized, what is a nice-to-have, and what is just an idea.
Lesson 2: prepare for unforeseen consequences
Around the time of the formal start of the hackathon (4 p.m. or so), the front-end developer declared that he will now “distance himself from the project” and I was told that I am now “the lead of front-end dev.” This came as a surprise to me and my colleague as we both joined with the expectation that there would be more people and less work. Oh well. Around the same time, Pro had the weekly all-hands meeting, so when one of my colleagues conveniently asked what is there to do on the weekend, I jumped in and said that we sure could use some hands. My colleagues stepped up and I felt a bit relieved.
These things sometimes happen during hackathons. Teams change, people leave, people join. You have to be agile and adapt fast.
The final deadline for submission was rapidly approaching, so we reviewed the must-haves and nice-to-haves. To my surprise, everything the project people deemed necessary was already present and working! We were good to go! It needed some visual fixes, though. You know, to make it prettier, more comfortable to use. The finishing touches.
Lesson 3: the weird curve of project preparation
This was a great way to start the morning – we had more people and could just take it easy.
But on the morning of the final day you’re never as prepared as you think you are. While for the first half of the day it was pretty chill, cracks started to show in everything the last hour before submission. Some people had done the same things in different ways, creating merge conflicts. I personally just felt like my brain wasn’t working that well any more. I spent at least half an hour just staring at my screen trying to come up with a way to access and manipulate the browser’s local storage from both React components and external utilities. I failed to come up with a solution.
The last half hour was the most stressful. Everything was bad. I rushed a lot, not handling the pressure well. There were 15,000 people, a 150,000-euro prize pool, and there was a huge merge conflict! In the end, we managed to get a working version up by the deadline. Not quite the full feature-set that we had hoped for, but good enough. I walked to my fridge and was immeasurably saddened by the realisation that I didn’t have any beer.
Lesson 4: the tech
This next part will be very focused on front-end development specifically, so feel free to skip it if you don’t care.
I fell in love with Formik. It’s the most comfortable form-building solution for React I’ve seen. A significant upgrade over the redux-form that we’ve used before, with a very manageable learning curve. I had looked at it before the hackathon, but this was my first experience actually applying it to a project, and I’m very impressed.
If you’re from my generation of React developers, you’re used to grabbing Redux whenever you’re building any sort of an application. Here’s some good news: I don’t need it anymore and neither do you! It has long been criticised for being high on boilerplate code. Nowadays, React Context and the React hooks APIs are more than enough for mid-sized projects. I’ve heard of people building huge applications just relying on those as well, but I’d be a little cautious of diving in head-first.
Lesson 5: impact of the work done
Our hackathon work resulted in a new ticket handling back-office application for kogukondaitab.ee – the system that connects people in need of assistance to a network of volunteers. It’s mostly aimed towards helping the elderly and quarantined. And it actually works! Call centres have been put up in Estonia and Latvia and the team behind Zelos is currently talking with partners from several other countries to get the system up there as well.
Despite the loss of sleep, the sudden changes in the team, and the stressful deadline, I had fun – I think we all did. And it’s great to be recognised – out of the roughly 50 projects that made it to the final deadline on our track, we finished in the top 10!
Lesson 6: the home office
For me, the idea of remote hackathons is brand new. But I think I like them! I am not a fan of the home office and can’t wait to get back to the real one – I don’t feel as comfortable or as productive working from home. But I think I would have felt even less comfortable and productive in some building where hackathons are typically held. It was nice to be able to be in my own environment, have home-made food, not worry about whether drinking beer or whether my clothing was appropriate. But I do miss the laptop stickers and free t-shirts.
Final thoughts
The Global Hack is just the beginning, and I’m sure there will be many more online hackathons in the near future. I recommend you check them out! Everyone and anyone can join – yes, developers and designers are often most sought after, but we can’t forget the value of people who come up with ideas, who do the copywriting, the presentations, the videos, and who look for the actual business cases and potential future partners for the projects.
The team behind the project has expressed interest in continuing with it for a week or two (as is customary with these things) and get it to the people that want to start using it to help others, but this is a whole different story. For now, I’d like to once again express my undying gratitude to my amazing colleagues for being a great team and encourage all of you to seek out online hackathons and join them. With a team or alone, there are always problems to solve!
