A couple of weeks ago I extolled the virtues of public speaking for tech nerds. Now it’s time to ruminate a bit on actually creating a conference session.
What makes a good session? A good topic always helps. And then it’s your job to explore that topic for 45 minutes or an hour. Some personal perspective turns a talk from just an infodump into a compelling narrative. And then you work and polish it. All done! Time for pizza.
Preparation for an hour session will take a chunk of time and effort (or at least it should). I typically have a 20:1 ratio of prep time to session time when I do a new talk. Luckily I can recycle material, giving the same (or similar talks) to multiple sessions of a regional conference, or to CocoaHeads chapters, local universities, or some other local programmer’s groups.
What to talk about? Obviously talk about something you already know, or something you can pick up. Ask yourself “What am I good at” and “What really excites me”. I’m pretty good at debugging and performance tuning. I also get entirely too excited those two topics. Those naturally became my first conference topics. Resist the temptation to learn something brand new before you present it. Debugging and performance I’m confident in, but I know I couldn’t put together an OpenGL session that wasn’t a waste of everybody’s time without at least a year’s worth of study.
Once there’s a topic, start researching. Keep notes. I have VoodooPads full of research. What might have been semi-interesting trivia a month ago might turn out to be vitally important. Read books. Read websites. Browse StackOverflow. Look at old code. Write new code. Play with tools. During this research phase some aspect of the topic will (hopefully) bubble to the top of your mind. That’s when I start sketching out the actual talk.
I haven’t settled on a great way yet for this sketching part. I might have an interesting sequence of pages in my VoodooPad. Sometimes it’s just a text file. Sometimes it’s a piece of paper. Maybe OmniOutliner. Sometimes I make an outline in Keynote, but not often. I find it hard to build a talk in Keynote if I don’t know where I’m going first. Plus there’s the distractions of prematurely creating slides, bullet points, and adding cool transition animations.
Once you get the framework in place, flesh it out. Add details. Add stories. When you think you’re done, you’re not. Go over it again. And again. Speak your outline out loud to the cat.
This is when I boil things down into a Keynote presentation. I know some effective presenters that eschew the Keynote / Powerpoint world, but I kind of like having stuff on the screen so that bored folks have something to look at while I drone one. Just don’t go nuts putting in special effects or finding the Perfect Stock Photography to illustrate your points, because things will change after you run it once in front of real people.
Find some Guinea pigs. I subject my local CocoaHeads to my conference talks before I give them. They also get subjected to new class topics for my Advanced Mac Bootcamp at the Ranch. It’s a friendly group, so I don’t have the “Ack! Strangers!” effect carbonating my belly. I also solicit feedback, as a group, and 1:1 with people that I trust. “Dude, give it to me straight, is this dumb?” I have good friends who give me good feedback.
Talks rarely escape the first presentation unscathed. Something you thought was going to be Completely Awesome™ ends up falling flat. Maybe nobody understands your particular approach to the topic. Something you ad-libbed as an aside might end up becoming the focal point of your session. Life is funny that way.
If you’re really brave, record yourself during one of these first-runs. It’s humbling. “I’m doing that with my hands? Is every third word really ‘uhhhhh’?”
You’ll probably discover that you’re trying to cover too much material, and you’ve gone way over your allotted time. It’s time to trim things down. That fascinating story about meeting Steve Wozniak on an airplane? Might want to save that for dinner conversation. That digression into the pros and cons of indexed indirection as it relates to superscalar nanoprocessing algorithms? (I have no idea what that means, either.) Maybe move that into its own talk.
Or you may discover that you’ve only filled fifteen minutes. That terrifies me. It means that my topic probably isn’t large (or interesting) enough to really warrant a full hour session. So it’s time to broaden your topic or abandon the idea and pick a new topic. It’s good to discover this more than 24 hours before giving your session.
Having spoken at a number of conferences, I’ve gone to a lot of sessions. I love learning. Some sessions you walk away from excited about some new tech or new idea. Some sessions you walk away from exhausted from the information overload (I admit I’m guilty of doing this to people.) And sometimes you leave a session because it’s a waste of time.
Things I really like in sessions: sharp focus on the topic, without a lot of digressions into trivia. Some personal anecdotes, though, are fine, and are generally welcome. It puts a human face on the technology. Jonathan Penn’s UIAutomation session is worth seeing if you ever get the chance. The whole thing is about the UIAutomation tool in Apple’s Instruments. Here’s UIAutomation. Here’s how you script it. Here’s it in action. Here’s a bunch of stuff he learned the hard way on an app. Here’s a cute animated pig. The Pig ties directly back to UIAutomation. Even if you’re not directly interested in UIAutomation, Jonathan’s presentation style is fantastic. You can tell he’s genuinely excited in the topic, and the enthusiasm is contagious.
As with every rule, there are exceptions. Sometimes the digressions are intentional, ultimately forming the structure of the talk. I love Daniel Steinberg’s keynotes. They’re usually a nice tour of a group of topics, sometimes seemingly unrelated, but before you realize it, he’s circled back around to the beginning and smacked you in the brain with a pretty cool conclusion that ties everything together into a cohesive package.
An engaged, excited presenter is a plus. We’re the ADD generation. We need some entertainment in our learnination. You don’t have to freebase caffeine before you go on, but being truly interested in your topic helps, as does a sense of humor.
In the Don’t category, please don’t read directly off your slides. It’s OK to read off your slides if you have a central point you’re hammering home (such as “Header files are the public interface for your class” from my Humble Header session). But remember that people can read much faster than you can speak. This is Presenting 101, but I still come across sessions that involve slides being read.
I like to have something up on screen that kind of sketches out what I’m talking about for that 2-3 minutes. Maybe some important bit of information or a diagram. This is also where I put in a visual joke, or some funny-yet-relevant quote I picked up from somewhere. It gives the folk out there something to do while they’re listening to you.
To demo or not to demo? I’m always frightened of demos, because the Demo Gods rarely grin upon me if I try to demo something too complicated. Some pretty consistent CocoaConf feedback I got early on was “yes this is all interesting, but a demo will make things easier to understand.”. So now I do more demos. Getting pushed out of your comfort zone can be a good thing.
Make sure your demos are actually interesting. I went to one session that was entirely one-liners typed into the terminal. There was a lot of “type type type backspace backspace return ERROR. oh yeah type type type backspace type type. And look! It printed out the letter q, which means that the command succeeded!” It was pretty much a waste of everyone’s time.
If possible, keep your demos self-contained. You never know how terrible a hotel wifi will be, or maybe your MiFi won’t have any signal. (I talked about similar horrors back in the summer.) Or maybe your cloud service provider decides to have a service interruption that day. Also, be very careful when doing any updates before a demo. The newest Xcode developer preview might completely break something you depend on, or they might have moved some piece of functionality to a totally unexpected location just out of spite.
Space out your demos. Good sessions tend to have some exposition, then a demo to show something related to that exposition. Then the demo suggests something else that’s interesting. Then it’s back to the slide deck for an exploration, then another demo, and so on. An hour really isn’t a lot of time, so you probably won’t have time for more than a couple good demos.
Practice your demos on the actual projector if you can. If your projector insists on running in 800x600 mode, you may need to adjust how you use Xcode. Also make sure that any code is large enough to be seen. There’s a Presentation style in Xcode that makes code larger. I try to get hooked up to the projector at least 10 minutes before doing a session, put up some code, and walk to the back of the room and make sure it’s readable. If my terrible vision can read it back there, most everyone else will be able to see it.
You can make custom settings with larger type if you’re using the terminal, or just enlarge things with command-plus. Don’t forget about screen zooming (control-trackpad-zoom). You can use this to enlarge important UI bits, or if you’re running in high resolution on a projector and want to highlight something that can’t be made larger inside the app.
Be sure to practice your demo transitions too, going from your slide deck to your demo applications and back. If you’re using a Mac for presentation and an iDevice for the demo, make sure the projector doesn’t freak out getting plugged or unplugged. If you use presenter notes on your laptop display (like I do), you’ll need to figure out how to arrange things so that the demo materials are on your laptop screen when you exit Keynote. I don’t recommend trying to do demos entirely up on the projector. I always get neck cramps from looking over my shoulder, and there’s just something about working the keyboard and mouse on a laptop but looking up at a big screen that makes it feel like “first day with the new hands”, and nothing goes right.
And finally, have an ending. Talks that just kind of peter out always leave me unsatisfied. I like having some closure at the end. It can be a wrap up slide that covers the highlights. If there’s one point you’re hammering home, some call to action, now’s the time to reiterate it. And then when I’m totally done, I give a ‘Thank You” to close it off nicely, and then if there’s time perhaps do a Q&A. If you do Q&A, please please please repeat the question. There’s not much more frustrating than a mumbled question and the response being “oh yes! Extremely important point I should have talked about!”, but only the people in the front two rows actually know what was said.
Be sure to stick around afterward. People may have questions they don’t want to ask publicly during a Q&A session. They might have an interesting corroborating (or contradictory) viewpoint. They might have suggestions on topics you might want to cover next time. Plus, people are fun to talk to, especially the nerds that populate conferences.
My next time to speak is CocoaConf / DC. I’m not sure what I’ll be covering. If you come, please stop by and say hi.
Interested in leveling up your coding skills from the same authors of the Big Nerd Ranch Guide? Subscribe to The Frontier today!