How to present at a hack day

I go to lots of hack days and hackathons. Some are big corporate affairs, some are boutique community events. They all have one thing in common - Geeks suck at giving demos.

You have 3 minutes to convince the judges - or your peers - that you've built something brilliant. How do you do that?

One Hundred and Eighty Seconds. It is not a lot of time. So here are my top 3 tips for succeeding at a demo.

Show the thing

This is the most important one. You need to show what you built. Demonstrate the thing that it does and what's clever about it.

The audience gets death-by-powerpoint every day at work. A good demo won't bombard them with slides.

Even worse, is a presenter who spends all the time talking about the problem, discusses their build environment in great detail, then runs out of time to do the actual demo.

I've literally seen someone spend two and a half minutes talking about why they hate Heroku and how they swapped to AWS - only to realise they have no time to show anything.

Here's my brief guide to showing the thing:

• Take 10 seconds at the start to explain the premise behind your app as simply as possible.
  • "I wanted to build an X, using Y, to fix Z."
  • That's really all you need to say. Your demo should fill in the gaps.
• Show the happy-path through the app. No one cares if your demo does password validation.
  • "When you open the app / website it shows you a thing. When you click on the thing, it does this clever thing."
• At this point, you can talk about the technology.
  • "It uses BlipSoft's AI library to talk to Funkenstien's middleware layer. We built a converter to recalcify the bytes."
• Show one or two other clever bits.
  • If the user uploads a picture of a cat, the interface dynamically changes to be cat themed!"
• Don't tell people what doesn't work.
  • If it can't handle photos of dogs, or if it crashes on a Tuesday, or if it only works on landscape Android phones running a bodged firmware... so what? This is a quick hacky demo. You don't need to martyr yourself.
• Have a definite ending.
  • "Thank you for watching! Any questions?"

And, you do need to demo something. Some PowerPoint slides are not a demo.

Keep to time.

This is also the most important tip. If you run over time, you're being rude to the audience and to the other presenters. The judges will not thank you for it.

You have a limited time - and that should be fine. You shouldn't build something in a weekend that takes more than a few minutes to demo.

Actively work to make your product quick to use. In these days of engagement metrics, it's hard to remember that your user probably doesn't want to spend much time using your product.

Here's a bad example I saw recently. The team had built a nifty AI demo which looked at a photo and gave back useful information. They'd built this into a chat-bot. And that's where things went wrong.

The demo they gave looked like this:

Bot: Hi! I'm Botso! Your vision companion! What's your name?

The presenter then typed "Hi Botso, I'm Jane. Nice to meet you."

Bot: Great to meet you too, JANE. Would you like to upload a photo?

The presenter then typed "Yes I would."

Bot: Cool, JANE. Your photo must be smaller than 4MB and be JPEG. Is that OK?

The presenter then typed "I only have a PNG."

Bot: Never mind JANE, I'll convert it. Click here to upload

All of that preamble might be good in a production app - but for a demo you can skip straight to the good stuff.

Rehearse.

So how do you succeed at the first two points? The same way you get to Carnegie Hall.

About two hours before the demo, stop coding. If you add anything new now, I guarantee you're going to break something.

Start a timer on your phone, turn the phone over, then give the demo. You have to actually speak the words aloud - not just in your head. Click through the thing you're demoing. When you reach the end, flip your phone over again and see how long it took. My guess is your idea of 3 minutes is different to the stopwatch's idea.

Work out what you can trim from your demo? Do you really need to explain your git branching strategy? Can your demo already be logged in rather than waiting for a 2FA SMS? Will the audience care about something you spent ages on?

If anything is seriously broken with your demo, fix it. But remove the temptation to add any new code or to change any of the outputs.

Go to the room where presentations will be taking place. Is there a stage? Is there a microphone? Does the WiFi work there?

In the half hour before the presentation, you and your team should run through your presentation repeatedly.

Stand up while you rehearse. Practice passing the microphone to each other. What will you do if a bit of the demo fails? Are you consistently finishing in under 3 minutes?

Isn't this a bit much?

Yes, possibly. I'm a bit obsessive about good demos. Brilliant technology is often hidden because of a crap demo.

Communicating ideas is an important skill. If your app cures cancer, but you spend 3 minutes talking about how hard a specific API is to use, no one will understand its importance.

If you only take one piece of advice from this blog post - just rehearse your demo a few times before going on stage. I see too many presenters who are genuinely shocked at how quick 180 seconds go by.

Your hacks are amazing - and you deserve to show them off in their best light.