May 4, 2020

How I Write Talks

New Workshop

Given the interest in the previous Alloy workshop, I've opened up a second day on June 22nd. Same discount applies, [redacted] for 500 off. It's still for a US time: doing a proper "Europe" slot would mean waking up at 5 AM for me. I'm still open to that, but probably not at the very beginning of doing public workshops!

If these two go well, the next workshop I do publicly will be a multi-day TLA+ workshop.

(I want to add workshop dates to my website but good site layout is haaaaaaard and I've been struggling with this for an annoyingly long time)

Office hours

Last week we did the late office hours experiment. My thoughts on that are mixed. On one hand, everybody who showed up was from the US, so it wasn't helpful for people outside the US. On the other hand, somebody mentioned that it was nice to have office hours that were after work for them. I'm still not sure what I'm going to do with this. But in the meantime, we're doing office hours at the normal time this week. So 11 AM CDT Friday, 4 PM UTC. Zoom room is 862 5489 7464, password is [redacted]. See you then!

How I write a talk

I have two major goals for May: update my alloy workshop and finally write that "are we really engineers" talk I promised I'd make back in October.¹ I have a bit of a fire under my butt right now because I promised to give the full talk early June. This is the longest I've ever delayed writing a talk and that's really worrying me. For comparison, I usually get antsy if I'm "only" editing the third draft by this point. But I only have like 10 minutes of this talk done, not very happy with them. Fortunately this is "just" a local talk, but still.

(I'm trying to be easy on myself. After all, this is kind of a stressful time to be alive.)

And because I'm very good at turning my own stress into marketable content, figured it would be fun to share my usual writing process. I did a gag thread about this on Twitter but it's not very informative of my actual thought process.

Warning my current process is probably overkill for some people, I tend to overprepare. You probably don't need to do all this to write a good talk.

1. Outline. A list of all the points I want to hit and the details of those points. I might not follow the entire outline, and in fact the essay might change pretty radically between the outline and the final talk, but having an outline makes it very easy for me to get started on the first draft. Once O have the first draft I can iterate on things to figure out what actually works and what doesn't. I don't necessarily know what I'm going to say at each part of the outline, I just know what I want to say.

2. Research all the points of the outline. This involves things like writing examples, finding primary sources all need, working out kinks in general arguments, stuff like that.

3. Script. This is where I really diverge from common practice. I write my entire talk out as a rehearsable speech. This is what the beginning of my empirical software engineering talk looks like:

   I'd like to start with a little exercise. Let's say you have a 40 line function, that you think youcan break down into four 10 line functions. Turning a big function into a few smaller ones. If you're confident that the small functions are easier to work with than the big function, please raise your hand.

   beat

   Okay, great, I see that's most of you. Next, everybody who thinks vaccines prevent diseases, please raise your hand.

   beat

   I think that's everybody in the room! Awesome, don't have to defend vaccinations. Finally, everybody who thinks it's more likely that small functions are easier to work with than vaccines prevent diseases, keep your hand up.

   beat

   If you look around, you'll see almost everybody lowered their hand. Why is that? Why do we believe two things, are confident in believing two things, but believe one more?

   This might seem excessive, but has a lot of advantages:

   • I know exactly what I want to say at each point. If I need to change something I can see exactly what it changes about the surrounding content.

   • I know how long each section is. My sweet spot for talks is approximately 130 words per minute. This means that if a section has 400 words in it, I know it will take approximately 2 to 3 minutes to say. Is that too short for the section? Too long? I can figure these things out and adjust them.

   • I don't need to memorize anything for the first draft rehearsals. I can just recite the script verbatim and see what works.

   • Version control. I can see how the talk changed from version to version.

   • If I haven't given the talk in a long time I can come back to the script to quickly reacquaint myself. If I'm giving a talk I haven't scripted out, I'll even write the entire script as part of the reorientation.

   Scripting is helpful enough that I've even written a vim configuration for .talk.md files.

4. Rehearse. At this stage you don't even have slides yet, I'm just rehearsing the script. I rehearsing and revising the script a couple times to myself. this help me find awkward sentences and gives me better ideas on the structure and content of the talk itself. By the time I start making slides I'm usually on version three or four of the script.

5. Start making slides. I'm really not a fan of slides in talks, I try to make mine more like a speech or storytelling than a presentation. The downside of this is I don't put nearly as much effort into my slides as I should. I tend to just use basic layouts that present information but aren't visually appealing. If there's one thing could I do to significantly improve my talks, it would be this.

   If the slides would be a super image or video heavy, I use PowerPoint. Otherwise, I use Beamer, a LaTeX package. The advantage of Beamer is I can do things like find/replace on my slides. Also its functionality for diagrams and revealing content is a lot better than anything else I've seen.

   (General rule of thumb: if there is a LaTeX package to do something, 1) it will be absolutely awful to use, and 2) everything else out there will be even worse.)

6. More rehearsing. Now that I have both the script and the slides I can rehearse with both. At this phase I can share the first draft of the total talk (first draft of slides, fourth draft of script) with friends and start getting audience feedback. This will usually trigger much more radical changes to the talk as I start to find out that certain things only sound good to myself.

   (Obvious question: why go through several rounds of revising the script if I'm just going to radically change everything after the first time someone else sees it? Because radically changing an already-revised script gets better results than radically changing a half past sketch. And it gets better feedback.)

   The last few things usually form a cycle of "write, rehearse, revise". This can happen three or four times for a talk. It also usually happens even after the talk is done if I'm giving it again, as I try new ways to make the talk better.

7. "Proper" rehearsals. These happen right before I actually give the talk and are there to make sure I have everything down solid. I'm less interested in doing significant improvements than I am in making sure that everything feels comfortable and natural. Usually I rehearse about once a day for at least the week leading up to the talk, usually more like 10 days or so.

   (If there was one bit of advice I can give to everybody who is interested, it's "rehearse". You can tell when a person has not rehearsed their talk. You can even tell when a person has scripted it but hasn't rehearsed it. That's when it sounds "rehearsed", as opposed to if they actually rehearsed. It's because their emphasis is all wrong, as if focused on reading what they have to say next versus what they're saying right now.)

8. If the talk is recorded I will later watch the recording and take notes. What went well? What could be better? I pay particular attention to my own posture and body language in the talk. Something can feel perfectly natural but look awful to the audience.

---

This is all for a talk I want to add to my "portfolio"- a talk that I expect to give multiple times. I used to feel bad about reusing talks until I realized that literally nobody cares outside of people who give talks. Talks that are short or that I only expect to give once are usually done much more loosely. I still follow the entire process but don't put in as many revision cycles or rehearse for a week straight. Last year I wrote the following talks:

1. A short 10 minute TLA+ demo
2. A five minute J demo (For the Ultimate Language Shootout)
3. A presentation on the Theorem Prover Showdown (as a guest lecture at Brown, which was crazy cool)
4. What We Know We Don't Know, the talk on Empirical Software Engineering (portfolio piece)
5. What We Can Learn From Software History, (Treated this as a portfolio piece, but IMO it's not quite there yet)
6. A presentation on advocacy and education at the TLA+ Conf (I didn't script this one and it went alright, IMO, but really underscored to me why I script in the first place.)
7. Designing Distributed Systems with TLA+ (portfolio piece but written in 2018- still did a lot of revisions this time around).

So I can write maybe two portfolio pieces in a given year, plus assorted short talks and one-offs. Currently AWRE is the only portfolio talk I had planned to write this year, which is part of why I'm annoyed I put it off so long.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.