My Process: Writing a Talk
Yesterday, I delivered a talk at Strangeloop. Actually, it was the morning keynote, but that was a last-minute surprise. Here is a video:
The process of writing and delivering talks is a tricky one, and I thought I’d try to go through mine in hopes of helping others.
Step 1: The invitation and initial thought process
These days, I usually get asked to give talks. I do not say that to brag, rather, to explain that the process of thinking about what I’m going to say starts when I’m asked to speak. I am grateful for this, because my best talks take a significant amount of time and creative energy to create, and often the hardest part is coming up with a title and abstract. The title is usually one of the last parts of the talk that I write.
In the case of Strangeloop, I was invited to speak in May, and once I accepted, the process of thinking about what I would speak on began. If you invite me to speak and I accept, unless I’m giving a variant of a talk I’ve already written (or even if I am!) chances are I’m thinking about the content from the moment I agree. I’m reading articles related to the content more aggressively, looking for insights in work that people are actively doing, blog posts they’re writing, other talks being given. I watched several talks from previous Strangeloops to get an idea of the type of content people typically present, in order to understand what the audience might be interested in.
Fast forward to June. I made a promise to myself that I would not think about Strangeloop until after I had finished writing my talk for Monitorama(note: turn on the cc, sound is messed up), itself a brand new talk for a new audience. Writing two brand-new technical talks at once is beyond me. In June, I started agonizing over what I would talk about. I asked my husband “if you could give a talk on one lesson you wish people writing systems today would really understand, what would it be?” I determined my personal version of this would be “testing”, and we came up with the clever (link-bait) title “Log Files Hate Me! One weird trick to cut your distributed systems bugs in half!”
Step 2: Despair, and a thousand drafts
I started working on the talk in earnest in late July. Unfortunately, this was also a pretty difficult time for me, as I had decided to leave my job at Rent the Runway, and was starting the long emotional process of tying up loose ends and separating. This made concentration difficult, and I had less time than normal at work to grab focused alone time.
I was also starting to doubt the topic. I looked at the code example I wanted to base it around, the tests for this issue in ZooKeeper. I thought about the story I might tell and I was exhausted by the work that I felt it would take to get from some ugly code to a working, thoughtful, talk.
I watched some talks on QuickCheck and property-based testing, the best being this one by Jessica Kerr. I realized that I did not have the time to learn how to do that in order to include it in my talk. I watched all of the discussions on TDD between DHH, Fowler and Beck. I grabbed an old copy of Code Complete, I grabbed a different book on software testing, I looked at blogs, I skimmed papers. I grew discouraged.
I wrote an outline, based on Mathowie’s excellent outline template. It talked about the stages of distributed systems. You can see the outline here. I tried to write slides to it. I got nowhere. I got very, very discouraged.
It is now August. I am spending a lot of time talking to Ines about how stressed out we both are about our talks. I am starting to doubt whether I can do this. My last edit to the testing version of the talk outline is August 14th.
I try different tactics. I think about writing a version of this talk around my talk on rewriting systems. I try this on September 4th. It goes nowhere. I think about writing A People’s History of Distributed Systems, based on the talk I gave at Monitorama. Reduce, reuse, recycle. This turns into a tour-de-force of reading about distributed systems. The outline for that version of the talk is here. I write this outline after delivering my keynote at The Lead Developer conference in London. I write a draft of slides for it, taking my Monitorama talk as the basis point and adding slide upon slide upon slide.
I have my last day at work. I give a Last Lecture, hastily pulled together but given from the heart. The slides are nothing but our company core values. It’s a good talk, and reminds me that it’s easiest for me to speak from the heart.
I continue to plough through my talk, now titled Distributed Systems: A Memoir.
Step 3: Panic, Deep Breaths, Finding the Audience
Luckily, my last day at work was September 15th. This gives me plenty of time to do nothing but think about Strangeloop and Cultivate full-time. Fortunately for me, Cultivate is writing itself. Strangeloop is a tougher nut to crack. I write a version of my memoir where I talk only about the lessons I learned writing my first distributed system, the risk cache. I have a realization about myself: I am not capable of writing about work that I have not myself done. Not writing a whole talk, anyway. I feel like a fraud.
So, I take another step back. I’m onto something with the memoir, the people’s history, the risk cache. I do an exercise to refocus me on the audience. Who are they? I described them as “curious, cautious, nervous.” OK. What is the unique point of view that I can bring that group? I thought of the comment I had made to my husband in June, that the concept of giving up hope and fear in exchange for hopelessness and confidence seemed like a good philosophy for systems design. I think about myself. I am pragmatic. I have written several distributed systems. I am a Buddhist. I have struggled through the years to be kinder to myself, to relax my perfectionism, to forgive my own mistakes. I want to give this to the audience.
On September 18th, I create the first draft of what will become the talk I eventually delivered. On September 21st I commit to the name change and new topic for good. I’m now definitely writing “Hopelessness and Confidence in Distributed Systems Design.”
Step 4: Write, Edit, Rehearse, Polish
Throughout this process I have been checking my work by standing up, putting on the slide show, and talking. If I can find things to say, if the words come and they make sense, I know I’m onto something. If I feel like I’m bullshitting, chasing around the truth, wondering what my own point is, I know I’m off. When the words flow and I find things to say, I know I’ve got the thread.
The outline writes itself this time, in fact, I didn’t bother doing a standard outline. I do a quick headline-generation brainstorming with sticky notes, which is a method I learned in a class from Decker communications. Three parts. Intro, 3 systems, conclusion. The trick is condensing the systems into something that the audience can follow without having to drown them in detail. Fortunately all of the work I did in the earlier steps have given me plenty of threads to hang on to. The two hard things about distributed systems. Distributed shared memory. Silence as a design principle. The fallacies of distributed computing.
I pull together pictures. Many of them are ones I’ve used in talks before. I’ve taken to saving images from twitter that I think will make good images for talks. I am reminded that it is good to give the audience emotional anchors, and I decide to use two pictures of my son for that purpose; one at the beginning, to represent sadness, and one at the very end, to represent joy.
I google font pairings because I’m starting to realize that the better my slides look, the more impressive people will think my talk is. Also Ines makes me want to do a better job. Once I decide on theming to tradeoffs, I go with the face/off font and a pairing. I put in a few highlight colors.
I run the talk by my husband. He points out that I think “Cache invalidation” means “Cache eviction”, thus saving me from a million well-actuallys. He also suggests the formatting of my Buddha meditating in the tire fire flames (originally, he was off to the side). Oh, and I should mention that calling Peter Bailis “Littlefinger” is entirely his joke. I put the finishing touches on the slide images Tuesday night. Wednesday morning, Alex emails me telling me that Kathy Sierra has had an accident and can’t make it, and will I do a keynote? I say yes.
I run the talk at least 6 more times. The only changes I make to the talk now that it is a keynote are philosophical; I openly acknowledge that I am attempting to give a dharma talk that can hopefully be applicable to a wide audience. I adjust my notes for highlights. I make sure I know the point. I go to bed at 10pm on Friday night.
I’m not sure I could tell you exactly how many hours I spent preparing this talk. Once I had the final idea, I probably spent 25–35 hours actually writing slides and rehearsing. But as you can see, I spent at least that much time before I even got to the final idea in preparatory research and exploratory work.
Summing Up
There’s plenty of tricks and processes you can use to help you get to a great final talk, but don’t expect them to work miracles. Breaking down ideas, brainstorming, thinking about the audience, consuming a lot of related materials, writing outlines, all of these things are helpful. But even with all of them, with all of my experience writing and giving talks, a great talk can still take a long time to write. So most of all, if you want to write a great talk, be sure to give it time.
