Jake Worth

• speaking

I’ve been giving technical talks for a few years, and I’m speaking at the Vim Chicago Meetup next month about integrating React with Vim. In this post, I’m going to use that opportunity as an excuse to document my speaking process.

Some smart people have written on this subject, and anything I’d have to say is partly inspired by these ideas:

• Conference Prompts: Or How to Submit Proposals and Influence People
• How to Prepare a Talk
• Improve Your Presentations In Under $50
• Speaking.io
• What I learned from reading 429 conference proposals
• What Your Conference Proposal Is Missing

Several of these writers talk about submitting conference proposals, AKA CFPs. I don’t plan to cover that in-depth. Why not? I believe once you can write a compelling proposal, getting accepted is the product of a variety of factors you can’t control. So, submit many proposals, and be like Thomas Jefferson, who once said: “I’m a great believer in luck, and I find the harder I work the more I have of it.” And in the meantime, learn to give a great talk.

I break my speaking process into four phases:

1. Finding an idea
2. Brainstorming
3. Researching and preparing slides
4. Practice and delivery

I can’t claim these steps as essential; they just help me. My target reader is somebody who wants to speak and has never done so before. I want you to walk away with encouragement and a step-by-step checklist for preparing a technical talk.

1. Finding an idea

First, I need an idea. What ideas lead to great talks? My strongest talks share the following traits:

1. I’m passionate about the subject
2. I already know the subject well
3. I’ve practiced the subject in the recent past

Here’s an example of a talk that has all three of these, my upcoming presentation at the Vim Chicago and React Chicago Meetups, ‘React.js + Vim’.

Passion ✅

Here’s why I’m passionate about this talk idea.

I love Vim. Learning this 25-year-old text editor changed my career. I went all-in on Vim three years ago and have translated my passion into organizing the Vim Chicago Meetup. And, I also love React. React is my framework of choice for the frontend.

Like any technical ability, writing React code well in Vim exists on a spectrum ranging from barely-getting-it-done to flow-state.

It takes work to build your Vim into the perfect React development environment. Writing React code means that I seek that perfection. What mappings, plugins, and workflow hacks can I use to get there? It’s a subject that I care about, and that’s a crucial trait of a good talk.

Familiarity ✅

An idea explored in Speaking.io is that aspirational talks, i.e.– “I want to know about this subject, so I’ll sign up for a talk and learn it by the deadline”– can backfire. I’ve heard this idea referred to as Talk-Driven-Development.

This approach doesn’t work for me. I have to start with a foundation of understanding. I need to already be at least at the same level as the average listener. Only then do I have a chance at pushing myself and my listeners, with enough work, into unfamiliar ground.

Freshness ✅

For passion to translate into an interesting talk, I need to have done the work recently. When somebody is speaking about an idea that’s fresh in their mind, the talk is better.

The ideas also have to be relevant to a developer working in the world right now. In the case of React.js, the JavaScript ecosystem is constantly changing, and any techniques I haven’t validated recently will likely be outdated.

Another benefit of talking about recently completed work is that I’ve had time to separate what worked and what didn’t. Those are often the most valuable points.

2. Brainstorming

Second, around my idea, I need to produce a lot of potential things to talk about. I call this brainstorming, and it’s the most the foundation for everything that follows. This step has two components: thinking a lot, and recording everything.

Thinking 🧠

To prepare a good talk, I generate a lot of ideas. Stephen King’s On Writing: A Memoir of the Craft contains a useful anecdote. As a young writer, King faced rejection after rejection. After many failures, one editor offered King some advice, hand-writing on his manuscript “Get rid of 10%.” King removed 10% of the words from his manuscripts, began submitting them again, and soon landed his first publishing deal. Repeatedly cutting 10% became one of his most valuable tools.

For every idea that makes it into a talk, I’ve rejected five. This slaughter is possible because I think about a subject for hours in an open-minded way. Thinking, while consuming prior art, listening to the people around me, reading code, and writing things down. With this mindset, I cultivate a long list of ideas that will help me fill time.

Leading up to a talk, I like to solicit ideas from my coworkers and the programming community. I’ve had some great conversations and received many ideas through our company Slack. Borrowing ideas from others makes your talk stronger.

Here is some of my current brainstorming list for my talk next month. I check off an idea when I’ve researched it. Ideas that I want to pursue further gets marked [x], and the rest get marked [-].

### Reactjs + Vim Talk Ideas

- [x] Build the talk from a blank virtual box
- [ ] Writing JS in Vim – Alex LaFroscia – Medium
- [ ] Investigate `.eshintrc` settings
- [ ] Go top to bottom through a JSX file and find optimizations
- [ ] Vim nnoremap: `\p — :! prettier %`
- [ ] Technologists often arrive at the same idea independently (PrettierJS)
- [ ] Linting solves needless churn and technical debating
- [ ] Ale plugin
- [ ] CLTab
- [ ] `CTRL X + CTRL L` - tab complete import statements
- [ ] Vim-surround plugin for JSX

Most of these ideas aren’t good, but they give me options.

This is a mental exercise, so I try to come at it rested, focused, and far ahead of the talk deadline.

Record Everything 🗒

I often use GTD for taking notes in a physical notebook. Whatever your method, be sure to capture every one of the great ideas you generate. Without a rigorous system of note-taking, I would forget a lot of ideas.

3. Researching and Preparing Slides

Third, I need to research and prepare my slides.

Research 📚

When possible, I start in an unusual place for tech: the library. Libraries contain a wealth of information on many technical subjects. Connecting a topical web development subject to the history of computers or human inquiry is something Sandi Metz, a speaker I admire, does well. Even when the material is spare, there’s always something, as well as librarians who can help you devise a research strategy.

Technical talks, often mislabeled ‘hard’ talks, are what I prepare most often. They require experimentation. I use the ideas I find to try a lot of experiments in my text editor or REPL. Which are worth talking about?

Preparing Slides 👉

After trying PowerPoint, Keynote, and even Vim buffers navigated with ]f and [f (an idea I borrowed from Steve Klabnik; not recommended unless you’re an unflappable speaker), I discovered Deckset.

Deckset is a feature-rich markdown slide builder, and I love it. If you know markdown, Deckset is fantastic. It lets me crank out ideas and proofs-of-concept right in my text editor. If you feel that the hardest part of preparing a talk is putting together the visuals and notes you need to speak, then Deckset is worth trying.

As for slide design, I follow the guidelines put forth in Speaking.io and the Chicago Ruby Meetup speaking guidelines. To summarize:

1. Make your text as big as you can.
2. Use the most basic code examples that you can.
3. Use high-contrast colors, like black text on a white background. Subtle monochrome palettes are unreadable on a projector.
4. Don’t show code unless you want your audience to read every line, because they will.

My talks don’t feature funny GIFs, pictures, or videos. Why? I’d rather be informative than funny. It’s a strategy.

I structure my talks like essays, with an introduction, thesis, three or four supporting points, and a conclusion. It’s formulaic but the formula exists for a reason.

Something I often ponder is: could this be a blog post? One of the less effective types of presentations could be characterized as a person reading a blog post they wrote. A telltale sign of such a talk is when the speaker concludes with a link to a blog post with the same title as the talk. I’ve given a few talks like this and they’re not my strongest. A good talk isn’t a recipe for solving some narrow problem, it’s a performance that couldn’t exist on a page.

4. Practice and Delivery

Lastly, it’s time to practice and deliver the talk.

Practice 🏋️‍♂️

Practice is everything! I run through the entire talk without stopping at least 10-20 times before any presentation. I do every rehearsal with a running clock, standing at a podium, projecting my slides onto something, even just a television screen, and even wearing the type of clothing I’ll be wearing at the presentation.

I practice setting up my equipment, plugging in the HDMI cable or Airplay, putting my devices into Airplane/Do Not Disturb/silent mode, setting up live coding sessions, and switching display preferences. I practice handling the loss of Wifi, my presentation software crashing, and even losing my computer. I find it challenging to do these things smoothly when standing in front of 300 strangers.

I practice staying in a time window by writing timestamps such as T: 10:30 in the presenter notes of each transition point in the talk. If I’m ahead of the timestamp, which is usually the case, I breathe, drink water, and walk around. If I’m behind, I speed up. At a Meetup you can get away with going long or short; conferences are expecting you to be pretty close to time because you’re part of a much larger schedule.

If you get a chance, deliver the talk once to a real audience of professionals. For a Meetup talk, deliver it first to your coworkers or friends. For a conference talk, deliver it once at a Meetup, the bigger the better. Just give it to somebody. Leave time for Q & A in the practice run; the questions your audience asks can be very valuable. Answer them preemptively on the next run, or add a section addressing common counterarguments or edge cases. The result will be a stronger argument.

Why do I rehearse so much? I get nervous, like everyone. When you’re nervous, you revert to what you have rehearsed. If you’ve rehearsed sitting down and mumbling, that’s what you’ll revert to. If you rehearsed going too slow and fidgeting with your slides, that’s what you’ll revert to. So, practice a lot, as realistically as you can.

There’s another benefit to this process: after running through a talk ten times, weaker material starts to stand out. Cut it. In this phase, I tend to get some of my best ideas doing mundane tasks like cooking. I can’t get into that kind of creative zone unless I’ve thought through the obvious parts of my idea and become almost a bit bored by it. And that takes repetition. A pertinent quote:

If I have ever made any valuable discoveries, it has been due more to patient attention, than to any other talent. — Isaac Newton

Delivery 📣

If I’ve been practicing, delivery is an afterthought. Knowing that I’ve put in the time makes me feel unstoppable. My only advice is to practice. Practice, so that you can enjoy the moment.

Two techniques I avoid: live coding and physical theatrics of any kind, and audience Q & A in the final talk. I’ve seen many talks fall flat due to an API that’s down, a drone that wouldn’t take off (although these are often some of the best talks, too), or a question that’s not a question monopolizing the Q & A. When in doubt, eliminate the uncertainty.

Conclusion

I’ll conclude with this Tweet from Saron:

Reminder: you don't have to be amazing to apply. Plenty of mediocre people with impressively high self confidence win everyday because they applied and you didn't. Throw your hat in the ring.

— Saron (@saronyitbarek) March 3, 2018

Public speaking isn’t magic. It’s a skill. The personal and professional benefits I’ve accrued have been worth every moment of self-doubt and nervousness. I hope you’ll give it a try.

What are your thoughts on technical public speaking? Let me know!