Preparing a Presentation
Posted June 11, 2013 by Katrina Owen
Two years ago at Nordic Ruby, Chad Fowler and Joe O'Brien suggested that I should submit to speak at a conference. I immediately rejected the idea. Speaking is difficult enough when there are only 3 or 4 people present. Let’s not complicate matters by introducing a room full of nerds, most of whom are considerably smarter than I am. I had no experience, and besides, what would I talk about? Everything I know I learned on the internet. Surely everyone else has read all the same blog posts as I have.
Both Chad and Joe admitted that presenting at conferences is difficult, and then added: “but it’s worth it”.
I couldn’t imagine how that would be the case for me, so I basically shrugged and responded yeah, no, I don’t think so.
They suggested I read Confessions of a Public Speaker by Scott Berkun, just in case.
I did, and about 6 months later I woke up one day and thought:
I should submit to speak at a conference!
Admittedly, I can be a bit slow at times.
A few months later, the abstract for Therapeutic Refactoring was accepted to Nordic Ruby, and I now had to turn my loose collection of ideas and code examples into a coherent talk.
Challenging doesn’t even begin to describe it.
Confessions of a Public Speaker is a great book with lots of excellent advice about actually practicing and presenting a talk, but it didn’t tell me how to put together a talk in the first place.
The earliest version of my talk contained 7 code examples. Only the second of these eventually made it into the talk.
For each of the examples I had exactly two slides: before and after.
An early beta-viewer of my talk gently pointed out that it was virtually impossible to understand how I had gotten from before to after, which made the whole thing seem like magic, which made me look smart and everyone else feel dumb.
Hm. Not quite the effect I was going for.
I spent several days meticulously writing out each step of the process: first writing characterization tests, and then refactoring the code.
Slides – Harder Than It Looks
At first, I tried doing screen shots of my code at various steps off of github, but within about two days I was ready to jump off a building.
I started combing the internet for advice about code in slides.
I got the idea of using
pygments from a blog post by Geoffrey Grosenbach of PeepCode.
Basically, once you have pygments installed you can copy code into your clipboard and run:
pbpaste | pygmentize -l <language> -f <format> -O style=<name-of-style> | pbcopy
This takes the text in your clipboard (
pbpaste), pipes it through
pygments, and then pipes the result into your clipboard again so you can just paste it wherever. In my case, ‘Wherever’ is Keynote.app.
Typically I use
-l ruby -f rtf -O style=presentation, where
presentation is a style that I more or less copied from Github’s syntax highlighting style.
After about 2 weeks of copying and pasting code into keynote, I had finished illustrating the steps of a single example. I showed this to my early beta-viewer, and the response was pretty encouraging:
Ok, I see what I’m looking at, but I have no idea why you’re showing me this.
In other words, I needed to provide some context for the example.
Context is stuff like “this code comes from a production application, and lives in a module that is over 300 lines long and does a bunch of different crazy things”.
After providing context, I basically had a detailed, dry, quite boring, step-by-step demonstration of a refactoring.
I needed drama.
The internet kept telling me that I needed a story arc, but I didn’t know what a story arc is, nor where I could get one. I tried to find someone who would explain it beyond: “It’s a story. In an arc.”
What I found was Nancy Duarte’s TED talk, The Secret Structure of Great Talks.
This suffers from a bit of proof-by-metaphor, but it helped me discover that I needed to hook people in with a problem statement or some pain that they could recognize themselves in, for example when I panic I write godawful code. Then I need to find the dramatic opposite of this pain, which is the point of my talk, for example refactoring can lead to flow and bliss.
After putting together my first talk, I concluded that
- You need a very clear point, and an argument that supports that point.
- It’s helpful to hook into people’s emotions at the beginning and the end, and approximately every 10 minutes to keep them engaged.
- Provide context about what you’re going to say, then say it, then provide perspective about what it means. Without that, the talk will have a single level of abstraction (all shrubs, no trees, no forest). That tends to be pretty boring and hard to follow.
- Practice. Some people say you should run through your talk 4 times before presenting it at a conference or user group. I think that this is off by at least an order of magnitude for new speakers.
- Use dark text, a light background, and a very, very large font size. Most rooms and projectors are NOT forgiving of light text on dark backgrounds.
Preparing a presentation is really difficult. Chad and Joe were right. It’s worth it.comments powered by Disqus