After the keynotes, the most popular sessions at most Perl conferences tend to be the lightning talks. Each session consists of about 10 to 15 lightning talks — talks typically lasting individually no more than five minutes — back to back. As well as being tremendously interesting and entertaining for attendees, the conference organizers recognize that they offer an unequalled opportunity for new speakers to present for the first time without going to the lengths required for a longer talk.
Which is why I was surprised that at this year's YAPC someone raised the point in the town hall meeting that there's no document that stands as a basic guide for pointing out the common pitfalls to new speakers. Armed with my experiences of YAPCs and organizing many, many London Perl Monger tech meets I thought I'd have a go at explaining what you need to know.
Lightning talks are a great way to start speaking, but they do come with their own potential problems. Even the seasoned presenter makes mistakes when presenting and has had lightning talks go horribly, horribly wrong. Luckily, Perl audiences are very forgiving when this happens — after all, it's happened to half the audience at sometime too, so it's nothing to get too worked up about. However, there are a few things you can consider when writing your talk that will prevent you from sabotaging your own talk before it even begins.
Make your Point
First of all, let's look at the point of a lightning talk. The point is to make a point, and explain it as quickly as possible. That's it. Understand?
Too many lightning talks forget this. They get caught up in the whole idea of providing background information or explaining other issues. They've got a full five minutes, damn it, and they're gonna use them.
Here's the secret; No one cares if your lightning talk only lasts four minutes. No one cares if it lasts three. I've seen talks that last two minutes and the crowd loved it. But everyone cares if it lasts six — especially if the important point you need to make happens at five minutes and 10 seconds. At a YAPC or other event with strict time keeping you'll be cut off at five, and no one will hear what you were actually trying to say.
One of the best tactics is to make your point as early in the talk as humanly possible. You might need to set up the problem space, explain why you were doing what you were doing before you can explain your point. Fine, but do it quickly. You really shouldn't spend more than a minute explaining the background before you make your first point. If you haven't explained the main point by minute three you're probably up the proverbial creek without the paddle.
Actually, that bit about not explaining much before your first point isn't really true. You see, if you're explaining the background to the problem, that itself has to be your first point. You must carry your audience along, keeping them interested until you hit what you consider to be the actual point of the presentation. You know how to do this — you know to generalize your problem into the larger problem that everyone has and therefore cares about, right?
Most Details Don't Matter
This brings me nicely to the bane of most lightning talks. The details. Here's the rub; No one cares, and even if they do, certainly no one will remember the little details 10 minutes after your talk has ended. This means that unless those details are absolutely necessary to explain the point you're trying to make, then they're just sucking up time. Even if they're necessary, stop and think, can you replace these with a shorter summary, something that you can explain easier? Remember, you're talking to an intelligent crowd here who can normally move from A to B without having to be handled through each and every step.
One of the biggest mistakes people make about the details is misunderstanding that just because they've put something on the slides it means that they have to explain it. For example, you might need to show slides to demonstrate that one of the things your spiffy new function allows you to do is rewrite a huge chunk of code into a much smaller piece of code. This means that you probably need a before and after slide with one slide containing a mountain of code and one containing very little, but it doesn't mean you have to explain how they're different in great detail. That should be self-evident (or if it's not, your new function isn't nearly spiffy enough.) Someone can always download your slides later if they really want to read the example carefully.
When it comes down to it there's only one way to make sure that your talk will fit in the time-slot, and that's to practice it. Read it out aloud several times. Present it to the cat. Try to convince your colleague/flatmate/significant other to listen to it. If you're presenting at a conference, see if you can present it at your local Perl Monger meeting beforehand as a dry run. Not only will this give you the most accurate understanding of how long it'll take to say everything (and believe me, you'll be surprised at what bits go quickly and what bits drag), but it'll also help you realize what bits can be cut and replaced. It'll also give you confidence and experience in the talk, so you can actually present it slightly quicker.
Having covered the contents of your talk, let's move onto the practicalities of how you'll do it.
Let's talk about slides. Firstly, do you actually need slides at all? You'll only talk for five minutes. Crib notes on paper work well. One of my favorite lightning talks had someone just talking from a bunch of index cards, each with one word on it to remind him what he was going to talk about next,. And each one he'd theatrically throw over his shoulder after he was done with it. Remember, the slides are to show things to the audience, not to help you remember what you're talking about. Think of the lightning talk as a narrative with visual aids — someone once told me presenting a lightning talk is just like having a conversation with the audience where they don't speak for five minutes.
Prepare your Slides
All this said, let's assume you've decided that you need slides. Remember, you have five minutes. This means that you have zero time to faff about with your slides, setting up your computer, or otherwise doing anything that isn't entertaining your audience. Preparation is everything.
The audience bores easily so it's important that you don't keep them waiting before you start speaking. If you have your slides on your laptop make sure everything is set up so you can start talking as soon as it's plugged in. Set up and load all the apps you're going to use first — no one wants to be caught on stage in an awkward silence with nothing to say while they wait the 20 seconds it takes Mozilla to load. While you're at it don't forget to close down instant-messenger clients, calendaring apps, and anything else that might randomly pop up dialogs when you're trying to speak.
It's absolutely critical that you take the time to check that your laptop works with the projector before the lightning talk session. Make sure that you don't have to do anything other than plug the projector in, that you don't have to remember some weird key combo to make the external display work, and that you have enough power to last the entire talk (including the time your laptop will be switched on while you're waiting your turn).
Of course, the best way to get around this faffing about with switching laptops is to work out who's talking before you and arrange to use their computer. One of the major drawbacks to this is, of course, that you might not be familiar with their setup. This means that you should, at the very least, run through your presentation. Don't assume that one web browser is like any other — they all have slightly different ways of laying out pages and having plugins installed. Try it first to find problems while no one is watching, rather than trying to debug your presentation setup on stage. Have your own laptop ready in case theirs suddenly fails for some unknown reason.
When it comes to actually writing a lightning talk, there are many choices of presentation software. Although there isn't one right piece of software for everyone, there are definitely wrong choices. That wrong choice is anything that requires any thought on your part while you're presenting. It's stupidly hard to operate a computer and talk at the same time — especially when you're not sitting in front of the machine but standing at a weird angle that makes it almost impossible to operate a mouse or track pad. During a lightning talk it's vital that you keep your rapport with the audience, rather than diverting your attention to the computer every slide change. Unlike a 40-minute talk, you don't have time to take breaks between slides.
For this reason I prefer software that you just hit one key or click the mouse to go to the next slide — I follow the rule that anything that requires you to move the mouse is probably a failure. So if you must present from a web browser make sure that the links to move between places are in the same physical location on the page, preferably in the top left corner. And make sure that you don't have to scroll your slides. Remember kids, HTML isn't a presentation language so the only way to ensure that it doesn't give you unexpected surprises — suddenly scrolling, missing graphics, crazy fonts — is to run through the presentation with the web browser you'll use on the machine you want to use beforehand. All web browsers do not render the same.
Even when you take every precaution, you'll still encounter unexpected problems. Your demo won't work. You'll discover you're using a slightly older version of the slides. Your software will use the wrong font. The computer will burst into flames and burn down the venue. Remember that you don't have time to recover from any of these problems. Even if it takes you 30 seconds to locate a new version of the slides and remember where you were, that's a tenth of your talk gone. More importantly, the audience has lost interest while you're doing this and has slipped into their daydream world where you'll have to work really hard to reacquire their attention.
If something goes wrong, you really have no choice but to move on and skip over it. As I said, the audience is normally a forgiving bunch so tell them something has gone wrong and take them into your confidence; explain what the demo would have shown and press on regardless.
Concluding your Talk
In an ideal world you'd be able to complete your lightning talk with time to spare, take a few questions, and clear up anything you didn't manage to cover. In reality, that's probably won't happen. So it's important to put something in your slide to allow people to find out more about what you're talking about and provide a way of contacting you once you're done speaking. The biggest mistake I've made in my talks in the past is putting this information on the last slide, which of course only appears for 10 seconds and no one has time to copy down. Now I place a simple URL in the bottom corner of every slide.
This just goes to show that I'm still learning and finding ways of improving my lightning talks. Remember that in the end, it doesn't really matter if it all goes well or not; it's all a learning experience. Good luck with your talk.