We’ve just held our first ever hackathon, and had a great time. Croissants were eaten, beers drunk and (a lot of) documentation was read, culminating in company-wide demos and 3 delighted winners. We’re planning to host a lot more of these, so we took the time to reflect on what went well and what we could do better next time!
Why did we do a hackathon?
Hackathons can deliver some real benefits, on top of being good fun. In our case we wanted to run it for 3 main reasons:
- Give our engineering team some creative freedom, outside of their day-to-day job
- Let them explore new languages and technologies
- Work with people they wouldn’t typically team up with
How did we run it?
We wanted to start simple - and have bigger plans for our next one!
Over the 2 days we kicked things off with a great breakfast for the whole company, with pastries, cereals and fresh coffee to get started on the right foot, full of energy.
Work started for teams of either 1 or 2 engineers. Since many of our employees love coding, we also had a couple of people from both our sales and product teams joining in on their own projects.
Some called it a day as usual at 6pm. Some went all in and were still polishing (or bug squashing) at 2am. Pastries were long gone.
The 10 projects were showcased during an all-hands hackathon demo on the Friday. Beers made an entrance, shortly followed by the first technical issues that mysteriously show up anytime a live demo takes place. Live bug fixes were a crowd favourite (less so for the presenters)!
In the end, 3 projects were rewarded and Andrew (for his real-time game), Rob (for his mobile app) and Aleks (for his sales automation) each got a great prize…
… With BB-8 another crowd favourite!
Playing with front-end real-time tech
Andrew started building a multiplayer version of the British game of Dobble, in which players must match 2 symbols. His focus was making it both as real-time as possible (no polling) and allow an unlimited number of players to join a same game.
Things went smoothly - although Andrew realised he’d under-estimated the time it’d take to get the math right to generate sets in which only 1 winning combination was possible. With some time left at the end, he polished his game by adding in sound effects and the logos of some of our vendors!
Explore new checkout analytics directions
Mike looks after our checkout in our product team. As you can imagine it’s quite the data-driven job and he’s a big fan of analytics, so he wanted to play with Google Tag Manager and the Enhanced Ecommerce plugin for Google Analytics.
His main goal was to explore whether these tools could be interesting to help us better understand customer behaviour on our checkout and ultimately increase conversion for our vendors.
Paddle.js to Google Analytics was straightforward. The hardest part was probably figuring out the format of data that Google Tag Manager expected to make the ecommerce tag work!
Mike was overall quite satisfied by his experiments: “It was really satisfying to see the data appear and to play with the funnels. Next time however I’ll probably do a more funky project that’s less related to work!”
Save time by running SQL queries within Slack
Maarten remembers fondly how Mark joined his hackathon project: “he physically tackled me”.
They both shared a same pain: getting a Slack alert at 1am and lacking context to know whether this was a critical problem. Every time an alert would come in, they’d need to start investigating, which took a lot of time (and repetition of manual steps) and wasn’t easy to share back to the team.
Their solution? Build a way for queries to be created within Slack, pulling data from a variety of sources (our database, our data warehouse Periscope…) and bringing in the required context within the Slack channel to make the whole team aware in situ.
They’ve continued working on it after the hackathon, with the goal to let more teams use the tool to answer questions such as “how many fraud transactions did we have today?” or let the customer success team find relevant information about a vendor ID. Making the tool GDPR compatible and prevent personal data from being shared is however the main priority before it can be used.
We’ve learnt a lot in the ops of running a hackathon. Go was a very popular choice, and our engineers mostly chose to tackle vendor-related projects.
We will probably make some changes for our next hackathon, which we intend to run once a quarter. Including the whole company rather than simply the engineering team, setting a theme or getting external companies and vendors to join in are all options we’re thinking about!