Presentations and Public Speaking.

October’s Central Ohio .NET Developers’ Group meeting was a series of “lightning talks” (15 minute presentations) instead of a single 90-120 minute presentation.

It was an interesting change of pace and, on the whole, went pretty smoothly. Granted, there were a few small hitches with changing between 6 laptops and speakers, but that’s to be expected and the problems were really incredibly minor.

I mentioned the meeting a couple of posts ago, so that’s all I’m really going to say about the meeting itself. The reason I’m doing this particular post is because of the presenter that I mentioned wanting to give some additional feedback to.

Unfortunately, I didn’t get a chance to talk with him directly. However, I started thinking that this topic might be important enough to generalize and make a blog post out of because so many of us have problems with public speaking and giving presentations.

As always, please keep in mind the words of Baz Luhrmann: “The long term benefits of sunscreen have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience.

“I will dispense this advice now.”


First off, relax.

I know that’s easier said than done. Public speaking makes a lot, perhaps even most, of us nervous (myself included even though I’ve had to do it before).

There’s not a whole lot that’s more nerve wracking than being the only person at the front of a crowd and knowing that everyone is looking at *you*. It doesn’t matter if it’s a presentation to the directors of your org, a political campaign, or a talk that you’re giving to a group of your peers. It’s always stressful.

Just remember that we’re not going to bite. Especially if it’s a users’ group or some other set of your peers that you’re speaking to. After all, we came there to listen to you, so why would we want to waste your time and ours by sitting there and heckling you (though we may occasionally joke along with you)?

For my part, I’ve done drama, had to represent the magazine I worked for at a conference (both the day of with the crowd and the night before at the dinner for the presenters) and have had to give more presentations for organization directors and management than I care to think about. Thankfully, I haven’t had to deal with being in a political campaign, but I’ve known plenty of people who have.

Even with that experience and knowing that mistakes aren’t the end of the world, I still get a serious case of butterflies and wonder how things are going to go (not to mention wondering why people are listening to *me* of all people). However, like most of the other speakers I know, I just try to make the best of it and somehow it all tends to work out fairly well.

How you relax is up to you. If picturing the audience in their underwear works for you, go for it. I’m not sure I’d want to do that with some of the groups I’ve talked to, but to each their own. Just take a breath, calm down, and be prepared to laugh off minor technical difficulties =]


Second - tailor your talk not only to the subject, but also to the group and allotted time.

Andrew, the software developer who gave the lightning talk last month that cause me to write what has become a novel of a blog post, chose to speak about Test Driven Development, a subject which I am quite interested in, but haven’t had a chance to dig into on my own yet.

He opened by saying that he was giving a longer version of the talk this month (November) and had just shortened it to fit in the 15 minutes allotted for the lightning talk. This was a pretty big mistake.

You wouldn’t give the same talk to a group of (largely) non-technical managers and directors that you would to a group of people who are going to be using and/or implementing the technology.

By the same token, there’s a lot of difference between how you structure a 15 minute talk and how you structure the same talk to last 60+ minutes. You can’t just cut off little pieces (or talk really really fast) and have it come out well – especially on a technical subject.

For a 1 hour talk, you can go into at least a little bit of depth, but in 15 minutes, you really have to follow the KISS mantra (and I don’t mean “They call me Dr Love”). In the case of Andrew’s presentation, the general outline of the talk should have probably looked something like the following:

1) Explain what Test Driven Development is
2) Explain why you want to use it
3a) Show a simple test or two by itself (probably no more complex than “Hello World” level stuff for this)
3b) Show the result of the test by itself (notably, probably a FAIL – we hope anyway)
4a) Show the code around the test
4b) Show the result of the test+code (We should hope that this one will PASS)

Instead of the above, in the interest of shoehorning what he had been designing as an hour long talk into 15 minutes, Andrew basically skimped on 1, killed 2-3, and did 4a&b with examples that were far too complex for the time allowed (or for an introduction level presentation, really).

In fact, he spent most of his presentation time mucking around with SQL and SQL Server as well as fighting with the web page he was using as an example. While this may have been alright for a longer presentation (depending on how he did things, but even then I would have went the KISS route), it really didn’t work for a 15 minute presentation.

In all honesty, he could have completely cut out the SQL and website and, instead, just written a few simple functions to show how to write tests for code and what the results should look like even in the longer presentation.

The end result was that most of the people in the room were looking at each other and wondering what was going on.

This could have been greatly alleviated if not eliminated altogether by doing the last thing I’m going to cover here.


Third – Rehearse.

You really need to do a number of dry runs of your presentation to make sure that you have the kinks worked out of the technical aspects, can make it fit reasonably into the time allotted, and actually know what you’re supposed to be saying/doing next.

Ideally, you would do your presentation a few times by yourself with all of your equipment and then, once you think you have it down, grab a few friends or colleagues and try it out on them as a sort of dress rehearsal, eliciting feedback before you give the “real” presentation.

It’s amazing how many problems can be prevented or corrected by just going over a presentation a couple of times. The major one, apart from timing issues, is that other people can point out things which aren’t immediately obvious to you such as parts of a presentation that may be confusing to others while they sound perfectly reasonable to you.

Think of it as a sort of peer review for your presentation instead of for your code. It’s the same idea, really.

So, having said all of that, it really boils down to three things – relax, be prepared (including being prepared to answer questions), and try to have a little fun with it. It will work better for you and your audience will thank you.

Current mood: Not bad =]
Current music: Depeche Mode – Everything Counts [Live]