In March 2019 about 30 engineers from Liberty IT will be heading over to our sister company Liberty Mutual in Boston for the 2019 Ignite Hackathon — a large-scale internal hackathon where employees from across the organisation (and the world) will compete over 24hrs to build new and innovative solutions.
I recently gave a talk in work to my colleagues who are doing the event for the first time and thought I’d write this post so others can also share the wisdom!*
*may not actually be wisdom.
What type of hackathon?
This hackathon is all about building new solutions for a global insurance company, but there are of course loads of different types of hackathons so some of this advice may make sense for some and not for others. Some hackathons are all about the $$$, some are about social causes, and some are just a great excuse to have some fun and learn something new.
The first thing to do before the event is to have a fair idea of what you want to create — which usually will start with:
For most company related hackathons the number one priority is business value — making your customers happier, making money or saving money.
This isn’t intended to sound crass, just realistic — business is about business. I’ve done a lot of hackathons where teams do amazing technical solutions, with awesome architectures hacked together overnight, but then they give a tech-heavy presentation and the judges can’t see where the business value is.
If it’s a technical hackathon, with techie judges, then absolutely knock yourself out and focus on the tech, but most hackathons I’ve done have been all about the business. There’s always one judge who likes to ask,”Where’s the revenue?!”
Successful ideas will likely have some of these in their favour:
- A clear problem to solve
- A clear way to solve it
- Figures to back it up
- A cool demo which is your chance to show off the great tech you’ve built
You should hopefully have the first three of those decided on before the hackathon! I’ve done events where we’ve only thought of what to build when we’re there, and that’s cool, but for the greater chance of success, you should probably know already what you’re going to build, or at least the main idea, beforehand.
Plan who does what (and when)
Presuming it’s not just you, you and your teammates should divide up research, coding, whatever, beforehand. There’ll likely be different areas — UI, API, DB, models to be trained, data to be sourced, feedback gathered, and much more. Knowing beforehand who’s doing what will help you plan both the tasks required and when to do them (more on that later).
Get an early night
Honestly — listen to the sage words of a guy who has had a few too many the night before, then realised in horror the next day that there’s no sleep anytime soon and The Fear during an AI hackathon is not really that much fun.
This can be difficult if the hackathon is in a different country, as it can all feel like a bit of holiday with coding thrown in, but believe me, a few refreshing glasses of sparkling water the night before and you’ll be glad the next day. Or a nice cup of tea, it’s up to you.
At the event, planning is again key — you and your team should have a good idea of what tasks you’re going to do, in what timeframes. This will allow you to spot if any tasks are taking too long; I’ve been at events where I’ve spent way too long on things that aren’t worth that much effort. 2 hours in and you can’t get something working? Maybe have a think if you really need it or can do it some other way.
Talk to other teams
One of the best things about hackathons is the chance to network with and learn from others. Some people think they shouldn’t give too much away to the competition but I think that’s a mistake. It highly unlikely some other team is going to steal your idea and you’re more likely to get inspiration for during the event, and afterwards, if you chat freely with other teams about your projects.
Sleep or not to sleep
I’ve a young baby at home so I know all about lack of sleep, but there’s something about not going to bed at all that most people just aren’t used to. My wife often reminds me at 3 in the morning that sleep deprivation is a form of torture, and regardless how excited and prepared you are for an all night hackathon, when 2am rolls around you’re usually regretting you ever heard about the damn thing!
You may have seen the Gartner Hype Cycle:
which is used to track technologies through life-cycle stages and usage. The Trough of Disillusionment is when interest wanes in a technology (Blockchain!) and that’s basically what happens at 2am in hackathons too!
This is the typical lifecycle of a 24 hour hackathon:
- Get there, super excited, find a good spot to setup (beside a window if possible so you can stare pensively outside like Bruce Wayne when things are really going pear-shaped. Pondering how to save your city / connect to your API through the corporate firewall … without too many casualties).
- Check out any swag and food on offer. Sweets! Limitless cans of coke! DONUTS!!!
- Get set up — power, wifi — and get started.
- A few hours of great work
- Grab some food, drink some coke.
- More great work
- The beginnings of doubt — it’s 10pm and you just can’t get it working. It’s ok, Stackoverflow will surely solve all issues with enough searching … right?
- It’s midnight, you and your team are taking a break, playing some games, drinking some coke, in one of the siderooms and talking about whether you should change approach. It’s probably too late though, yeah?
- 00:30 am — PIVOT!
- It’s 2am — the Trough of Disillusionment! The Witching Hour! You and your teammates stare at each other blankly, blankets wrapped around your shoulders as you stare in dejection at broken code. You look at other teams, either enthusiastically coding away happily, or sleeping on folded arms, their snores almost as annoying as the 178 red error messages in your IDE. Maybe … you should get some sleep too?
It’s entirely up to you but I’d suggest not sleeping unless you really need to. Sometimes what’s worse than no sleep is a tiny bit a sleep, where you wake up groggy and wishing you were still asleep.
And if you make it through the Trough of Disillusionment …
- 4 am — it finally works! High fives all round, and some more coca-colas! Any excuse!
- 6am — polishing off the slides for the presentation
- 6:15 am — a quick idea … how about we add a chatbot, just a little one, for the interface? Super easy, we’ve done loads of chatbots!
- 7:55 am — FIVE MINUTES LEFT!!! Teammates shouting at each other! “Just comment out the chatbot!”, “Why won’t it merge!?!!”
- 8:00 am — it’s done, code committed, all over!!! More coca-cola!
I have to say though, in the interest of not getting sued by anyone — you decide if you need to sleep or not! All advice here is taken at your own risk!
What about afterwards? That depends on what happens at your hackathons — some may have judging straight away, some will have it later or the next day. Whichever it is, you should be prepared for the demo well before now — if possible you should have practised your demo before the event, in the anticipation that you would get it all actually built in time!
I could write an entire post on what makes a good demo, but for now, some quick pieces of advice:
- No time wasting — don’t waste time introducing every team member, or talking about anything not related to your idea like the teams or companies you are from. Just focus on what the judges need to hear, namely:
- What the problem is.
- How you solve it.
- The benefit of doing so.
- Keep it clear and simple to understand.
Finally, one piece of very important advice:
Seriously! The last 24hr event I did, I was too tired to stand up for a shower so decided I’d have a bath! I woke up an hour later, thankful I hadn’t slipped under the water in my sleep and died! Really!
Just so I don’t end on that slightly depressing note, the other piece of very important advice about the whole thing: