A couple of months ago I presented at LoneStarRuby 2013 in Austin, Texas. While I’ve done a few presentations for work and locally in the past, I’ve never presented at a proper developer conference before. I knew from experience that the standard of presentations at Ruby conferences will tend to be pretty high, so rather than risk being the token crappy presenter (that you occasionally see - and feel sorry for), I set out to do a bunch of research on what makes a decent presentation. Watching videos by such presentation luminaries as Ben Orenstein and Scott Hanselman, as well as reading old favourites like Presentation Zen and Confessions of a Public Speaker. In the next few paragraphs, I’ll show you my talk as well as try to distill everything I learned and hopefully save some fortunate developers hours of effort in the future.
First thing first, here is the video of my talk, I’d like to think I did OK and all my preparation paid off. The title of my talk was “Why You Should Love The Command-Line And Get Rid of Your Rake Tasks Once and For All” and it was about the shortcomings of Rake and what we would use instead if we wanted to abandon it as a community (here is the full conference program description).
How To Actually Get To Speak At A Conference
In my case it was just a fortunate chain of events. LoneStarRuby decided to do things a little differently this year and asked the community to nominate people they’d like to see present at the conference. People would then vote for the nominees and the most requested ones would get invited to speak. I was lucky enough to get nominated and then even luckier to get some votes, so this opportunity essentially fell in my lap.
However getting invited to speak at a regular conferences is actually not that difficult. Most conferences have a ‘Call for Papers’ (e.g. RubyConf Australia 2013) a few months before the conference actually runs, people submit descriptions of their talks and the conference committee then decides who to invite to speak. Usually a conference would get a couple of hundred submissions at most, sometimes significantly fewer:
Wow, 80 talk proposal pull requests for RubyConf AU! Thanks to all who submitted. It's going to be tough to choose 22.— RubyConf Australia (@rubyconf_au) October 31, 2012
So if you have a good talk idea and submit it, you have a reasonable chance of being accepted. To put things in perspective, a decent software job gets several hundred applications for one position. Here you have a couple of hundred proposals for a couple of dozen spots! So, pick a few conferences and submit your ideas, the odds are good.
Writing A Presentation That Kicks Ass
Before you start writing your presentation there are a few things you need to do, a few things you need to get, and a bunch of choices you need to make. Let’s look at these one by one.
Use a computer you will actually be using when you deliver your presentation. Seriously, don’t write the presentation on one machine, and present using another! Use a machine you know really well. It may not seem like much, but if things go wrong, it can be the difference between knowing exactly what to do and hunting around (that is the difference between looking like a boss and looking like an idiot).
Get a presentation remote straight away and make sure it works well with your set-up, it’s just one less thing to worry about allowing you to focus on the presentation. I use the Logitech Professional Presenter R700:
It’s small, has a nice laser pointer, and works well. Not all features work with a Mac, but it’s definitely good enough.
Before you even start to write any slides, write out your presentation in long-form as if you were writing a blog post. Don’t restrict yourself in any way here, put down everything you can think of. Do this over the course of a few days to let your ideas percolate. It will let you organise your thoughts, you’ll have all the text you need for the presenter notes and you can print it out for reference when writing your slides. In fact, if you read this document slowly enough, slides will tend to just fall out of it, making your job that much easier.
At this point find out how long your presentation should be, this is not always obvious. Sometimes they need to be 30 minutes, sometimes 40, 50 or 1 hour. E-mail the conference organisers if you have to, but find out as early as you can. It doesn’t really matter for now, but when you start to practice you need to know what to aim for.
I spent hours trying to pick the right Keynote template and the right fonts. We have a whole marketplace for this kind of stuff at Envato. I got it down to a shortlist of over a dozen templates which is when I realised that my time is probably better spent focusing on my content rather than comparing the merits of slide templates. So I ended up going with generic slides, white background, black text, and Helvetica for the font. You’re not going to wow anyone with your design acumen, but you also won’t make anyone puke too much. And it’s totally liberating not having to worry about this stuff, focus on writing your presentation instead. And if this doesn’t convince you, remember that it’s all about high contrast - black on white is perfect in that regard. The projector is FAR crappier than your nice retina screen. Subtle colour differences are lost, and what stands out on an LCD is often not visible at all on a projector.
And while you’re at it, find out what resolution the projectors at the conference venue are (once again you may need to e-mail the organisers), use a slide template that matches the projector resolution or it will definitely look bad.
Presenting Without Making People Cringe
There are no shortcuts for this, it all comes down to practice. I don’t mean experience, I mean practicing this particular presentation that you have just written. When you finish the first draft of your slides, start running through it, out loud, in front of a mirror. The first 2-3 times you can use to tinker with your slides, remove things that don’t work, make sure the whole thing flows well. When you start, your talk will seem way longer than it should be, but don’t prune anything just yet. The first time I ran through my presentation it took me over an hour (aiming for 35 minutes), but I’ve subsequently done it in less than 30 minutes. The lesson is, don’t prune anything until you can run through your presentation twice in a similar amount of time.
After a few times practicing out loud on your own, you will feel better about it, this is when you can present to a couple of friends, or your wife, or your mum. It doesn’t matter if they won’t understand it. The idea is to make it a little awkward for you, so that you’re more confident in a slightly uncomfortable situation. The people you’re presenting to are just a rubber ducky.
After this you can present to your co-workers, or a local user group which will let you get some feedback and some more nice practice time. At this point, your slides will be getting close to their final state. Now, you can go back to practicing on your own again. The goal here is for you to get as close as you can to memorising your notes.
Overall I practiced my talk about 12-15 times before I presented it for real (that’s at least 6 hours of pure talk time). The more practice you get under your belt, the harder it will be for any unforeseen circumstance to throw you off your game. And if you think that’s too much time, watch the LoneStarRuby 2013 opening keynote by Sandi Metz, there is a moment where she talks about researching that keynote for the last six months - hard to compete with that if you try and ‘wing it’.
Many people are under the impression that if you’re doing a developer presentation you always have to have a demo. I totally disagree with this, just about every presentation with a demo that I have ever seen has had something go wrong with the demo. From minor glitches/syntax errors, to total and complete failure. So, unless you’re very confident, have had a lot of practice and are extremely good at recovering on your feet, don’t use demos during a conference talk (save it for local user groups where people will cut you a bit more slack). Take static screenshots and put them in the slides, or if you really want to show a working something, record a video then play it and talk people through it. Whatever you do never ever rely on internet being present, I am yet to go to a developer conference where there were no issues with the internet!
Fitting Into The Time Frame
People often speak faster when they are nervous, so their talk will run short. If you’ve practiced enough, you should have no trouble with this. Going over is another matter entirely, when you know your material well, you tend take detours because you know you can always pick up where you left off. Don’t deviate from your notes, if you want to take a detour or make a joke, put it in your notes.
A trick that some people use is to make all your important points upfront then just expand on them one by one subsequently, that way you can stop at any time since you’ve already made your main arguments and therefore you never run over. I don’t like this, it makes for an unsatisfactory story that ends nowhere. A presentation should have a beginning, middle and an end. Fit into your time frame by practicing.
General Tips For Succeeding (Or At Least Not Failing)
Here are some general tips that will save you some headaches.
If you can find one, hook your computer up to a projector with the same resolution as the one you’ll be using at the conference. This way you can work out all the connectivity issues so when you connect at the conference things should just work.
Your presentation should entertain first, inform second and teach a distant third. It’s very hard to get people to learn anything in 30-60 minutes. But you can make it fun while showing them something interesting. Imagine you’ve been awake for 48 hours, and you just had lunch and now you have to listen to some guy talk about code when all you want is a siesta (not too far from the truth). Will you put this guy to sleep, or perk him up a little bit?
If you have serious stage fright, you can take some beta blockers (you’ll need a prescription), but don’t do it unless you know how they affect you i.e. you’ve taken them before. I don’t tend to get much stage fright, but I certainly feel much more anxious if I don’t know my material well. So, if you’re prone to stage fright, practice again and again, it will help more than you think.
Lastly, know what kind of flyer you are. It turns out when I cross over enough time zones in a short period of time, I feel extremely unwell for several days afterwards. I suspected this would be the case, so I arrived a few days before I was due to speak, which gave me just enough time to recover (barely). So if you’re flying a long way to a conference, make sure you give yourself enough recovery time (if you’re like me and need it). No matter how much you’ve practiced, if you’re feeling sick while presenting, it will not go well.
I hope these tips help you anticipate anything that can possibly go wrong so that you kick ass next time you present.
Image by Reality Side B