I’m not a huge fan of the live demo in conference talks – it’s really hard to do well so I see a very large number of bad ones. Also, it’s super hard work to include them in my own talks in a meaningful way because they are so difficult to pull off. I could write a very long list of reasons not to ever live demo (nobody wants to watch you type, now you are talking to your laptop, conference wifi rarely works, you could tell me three much more useful things in the time you’ve spent doing this …) but in truth as developers we love the “new shiny” and it can be super helpful to get an actual walkthrough of how to do a particular thing. So if you absolutely must live demo, here’s my own general plan and tactics:

What’s The Value?

All conference talks should start from a written list of outcomes for the attendees, long before any slides are made. You are giving attendees something, whether it is skills, knowledge, enthusiasm – the talk is for the attendees to become more awesome, not for them to realise how awesome you are. So with that in mind, what does your demo give them that is of value?

My rule of thumb is that if it’s useful or confidence-building to show the moving parts, then do it. For longer time slots as well, there’s more space for this – in a training session or workshop I will almost always demo and/or live code. Conference talk slots shorter than 45 minutes almost never get any demo content, the short slots are performance pieces. Example of a good demo: I love to demo git bisect because while nobody will remember the exact commands, once you’ve seen it working, you will always remember that it exists and maybe even what it is called so you can google for it! Example of a bad demo: typing 10 lines of code that could have been put onto a slide or at least prepared ahead of time.

How To Communicate

It’s incredibly hard to talk and type at the same time. Much harder than you think. I’ve been doing this as a speaker and trainer for nearly a decade and I’m getting much better but it’s still super hard! Consider how you can show what you do, and still explain to the audience what you are showing them; don’t say what you are typing, say what you are doing (e.g. “first we configure the client, then we send the request …. this next bit checks the status code and works out what to do next”). I give one talk where I talk and type almost all the way through with my screens mirrored (you need to mirror to demo, trust me) and therefore reading commands off a printed paper script as I go along. It works (see https://www.youtube.com/watch?v=duqBHik7nRo) but there’s a hundred hours of prep to get to this level. I kind of wish I was exaggerating, and I did build this talk up over time, but yeah. A hundred hours.

An easy hack here is to simply record a (silent) screencast of what you want to demo – then you can play the video while standing up properly and speaking clearly to your audience rather than mumbling with your head in your laptop. At the risk of giving away all my secrets: use a video player that allows you to change the keyboard shortcuts (try VLC for Linux/Mac) and map play and pause to forward and back on your presenter remote, and record the video without any long pauses for explanations. This way you can keep the playback and the explanation in sync while you run around on a big stage telling a great story!

Pro-tip for screencasts: don’t forget to copy the screencast(s) to your USB backup stick as well as your presentation slides. Just in case!

Be Prepared

Internet Connection

Is it possible to make it not rely on the internet connection? I like to set up a repeatable development environment with everything I’ll need – for example I have one vagrant box with CouchDB, RabbitMQ with a bunch of plugins, a webserver, some endpoints and a local copy of requestb.in so that I can do a full webhooks demo regardless of the status of the connectivity at the event. If something goes wrong, I can destroy and recreate the vagrant environment. (The repo with all that in is on GitHub if you want to look at my approach)

If you really need an internet connection (I’m now a Developer Advocate for cloud things), ask if there is a separate one for speakers. I sometimes demo with IoT stuff and recently I did one with the Amazon Echo. That device knows how to connect to my mifi which I had charged and added credit to, and to my phone hotspot. I also brought a battery that could run both the echo and the mifi for a few hours in case there wasn’t power at the podium.

Cheatsheet

Most talks have a slide deck, but for a demo I create a second deliverable: the cheatsheet. This is a printable piece of paper (because my screens are mirrored!) with prompts to get me through the demo. It stars off with “Start the vagrant machine, make sure the tests database is empty” and has a combination of commands to type and reminders like “Now STOP and explain what rebasing is before you do the next bit!” to help me to juggle the combination of communicating and demoing. Even if I don’t need a whole printed set of stage directions, I sometimes use a single index card of notes if I feel worried about forgetting which slide is next (all right, I always feel worried and often have this in my back pocket in case of panic).

Stage Setup

Given that you need to mirror in order to demo, you now need to be able to give the whole of the rest of the talk without your presenter second screen. I sometimes put my phone in airplane mode (do this during all talks so that the phone can’t receive incoming anything and also can’t send notifications to your wearable tech!) and put a timer app on there, since I have one that I use when rehearsing. Also consider if you are doing a mostly-terminal or mostly-white demo that this will wildly light up or dim the room which can be jarring for the audience – I always use a dark-themed slide deck if I need to switch to my black terminal at any time.

Related: make sure your fonts are big enough. You are close to your laptop screen and for an online session it matters a bit less (but someone always tries to watch on their phone) but for an in-person presentation make sure your fonts are as big as those on slides. For your slides: print your slide deck on paper with 12 slides to a page. If you can’t read it at arm’s length, go bigger on the font size. Nobody ever complained that the slides were too clear and easy to read!!

Pro-tip for making slides more accessible: upload them in advance and either tweet the link before you go on stage or put the link on the front page of the slides (or both). Plenty of people find it easier to invert colours, zoom in, or otherwise work with a slide deck they can use on their own devices.

Always ask beforehand about microphones. You can’t hold a handheld mic and type so you may need to drop or use a video of a demo if that’s what you’ll be using. Also never ever say these words “I don’t need the mic”. If the majority of humans in the room can hear you then that’s nice, but the video recording can’t and neither can anyone who is hard of hearing. (I wrote a whole post about microphones if you’re interested)

Ask about the lectern/podium as well, including requesting a photo of the setup. It’s almost impossible to live demo successfully with your laptop on a table (also ladies, you may need to tape your clothing if you are in the situation of needing to lean over a laptop to type). If you are able to stand, then never sit down, not even for a quick demo. It’s much more difficult for people to see and hear you when you sit at your laptop (or indeed address your remarks to it at all – see earlier suggestion to screencast instead), so bring your presence and your attention to where they belong: on the audience.

Plan B

The Amazon Echo demo needs working cloud services, local internet connection (of which I had three options and ended up using the venue wifi), power (which I brought a backup of) and sound connection (I’d requested this in advance and also tested how to do work with the device and a handheld mic). Those are just the plan A. Plan B was that I had clearly labelled videos of all the demos I planned open in the video player on my laptop when I delivered the presentation. Plan C was the the slide deck and videos were also on a USB stick that I had in my pocket; due to setup problems, we were onto Plan C at one point although I did eventually present from my own laptop in a place where I could see (but not reach) it.

The Finish Is Only As Good As The Preparation

The rehearsal part of talk preparation is easy – especially once you’ve covered the elements above. It takes 40 hours to prepare a 1-hour talk, and probably half as long again to design a repeatable demo that you can do in a slick and understandable way every time. Practice with the second screen setup that you will use (you’ll be mirrored), and also include saying whatever words go with in whichever language you will be presenting in, and rehearse against the clock so you know exactly how long each piece will take. Train like an athlete and then train again until you will produce informative and polished results even under pressure. Good luck!