Emily Morehouse

On My Second Conference talk


Less than 6 months ago, I wrote a retro on my first conference talk. Since then, I've already learned a lot and want to share that knowledge and continue with my ritual of sharing the reality (read: my reality) of speaking at conferences as open as possible.

If you didn't read my previous post, you don't necessarily need to, but you may want to reference these:

You may also want to check out my second talk repo and code examples.

Time Investment

Here's a breakdown of the time I spent proposing and preparing my first and second conference talks:

  • The AST and Me:

    • Proposal: 2 hours
    • PyCascades prep (Conference 1): 36 hours
    • DevOpsDays YVR prep (Conference 2): 2 hours
    • PyCon prep (Conference 3): 6 hours
  • What To Expect When You're Expecting:

    • Proposal: 4 hours
    • DinosaurJS prep (Conference 1): 23 hours

So all in all, from proposal to first presentation I spent 11 hours less preparing for my second talk than my first. Some of this is definitely based on the type of content I was working with. I spent a lot more time creating diagrams for The AST and Me, though I probably spent about the same amount of time trying out ideas and getting code snippets together.

Talk-Writing Technique

I took a very different approach to writing this talk because I was having some major issues getting started and didn't have time to waste spinning my wheels. After revisiting my outline, I pulled together a couple of resources that I knew I wanted to include. From there, I pulled out my voice memo app and just started talking! Anytime I found a snag, I'd hit 'pause' and revisit my outline or resources for something that flowed nicely from what I'd already said. I got about 12 minutes of talking out of my first go. I then proceeded to transcribe and turn it into speaker notes and slides.

I found that this technique worked wonders at establishing the flow of my talk (seriously, my entire outline was rearranged). It also basically wrote half of my speaker notes, which made it super clear what I could pull out into slides to go along with it.

Your Proposal Isn’t Set In Stone, Revisited

My proposal for my first conference talk proposal felt massively different than the finished product. I added new topics, cut a bunch of old topics. However, for my second talk, I feel like it stayed fairly consistent with the exception of organization updates and a couple of additions. Honestly, from the time I submitted my proposal on February 9th to the time I actually wrote my talk starting on June 17th, I couldn't even remember the details of my outline. After pulling it back up, I realized that I had basically already written the talk!

Don’t Worry About Perfection, Revisited

I made some terrible mistakes with my time for this talk. I actually stayed up until after 2 AM the night/morning before the conference, fighting to get my code snippets to run in a full test environment. You know what? It didn't matter. I wasn't planning on demoing anything, I was just being stubborn (not that I've EVER been told that). And let me tell you -- I could have used the sleep WAY more than the peace of mind having working code examples that I easily could have done afterwards.

Practice Makes... Practice

At this point, I feel like I have a decent rhythm for proposing and creating talks. I have a solid outline structure that people love (feel free to steal it!). I stick with a slides library that is super easy to work with, allows my presentation to be portable, has great syntax highlighting support, and lets me write everything in Markdown (very convenient for copy/pasting from my notes/outline that I keep in Bear). Each time I go through this process though, I intend to keep iterating. More boilerplates, more tricks and optimizations for allowing my time to be focused on content creation.