How to survive a 24 hour hackathon

Andy O'Sullivan
Jan 27, 2019 · 7 min read
Image for post
Image for post

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.

Before

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.

Image for post
Image for post
Generally if you take care of the first one, the next two will follow.

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.

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).

Image for post
Image for post
seriously

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.

During

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.

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.

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:

Image for post
Image for post

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?
Image for post
Image for post

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!

After

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:

Image for post
Image for post

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:

Image for post
Image for post

If you’ve any thoughts or comments, let me know below, and you can get me on Twitter or LinkedIn. Check out Liberty IT here. Thanks, Andy

LibertyIT

Liberty IT thoughts and tech stories on technical…

Andy O'Sullivan

Written by

Innovation | http://appsandbiscuits.com | Tech for Good Dublin | Gaeilge | all content my own opinion

LibertyIT

LibertyIT

Liberty IT thoughts and tech stories on technical leadership, digital transformation and agile software delivery.

Andy O'Sullivan

Written by

Innovation | http://appsandbiscuits.com | Tech for Good Dublin | Gaeilge | all content my own opinion

LibertyIT

LibertyIT

Liberty IT thoughts and tech stories on technical leadership, digital transformation and agile software delivery.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store