December 29, 2017 • 2 min read
I’m writing a blog post series about preparing technical talks, here are the five parts:
Today, I’ll be covering the third step of my process: researching and preparing slides.
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 and emulate, does well. Even when the material isn’t there waiting to be found, there’s always something, as well as professionals 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 found during brainstorming to try a lot of experiments in my text editor or REPL. Which are worth explaining?
After trying PowerPoint, Keynote, and even Vim buffers navigated
[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 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 speaking guidelines. To summarize:
My talks don’t feature funny GIFs, pictures, or video. Why? I don’t trust myself to be funny, and don’t want to invest any of the time I have to prepare on that quadrant. It’s a strategy.
I structure my talks like essays, with an introduction, thesis, 3-4 supporting points, and a conclusion. Formulaic, but it works.
Something I often ponder is: could this be a blog post? One of the less effective types of presentations could be summarized 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 like this that I didn’t love. A good talk isn’t a recipe for solving some narrow problem, it’s a performance that would fall flat on a page.
Researching and preparing the slides is a unique process and these ideas have worked for me in the past. Experimenting and automating my process has helped me to develop talks that are detailed and hopefully interesting to watch.
Next up in this series, I’ll be covering the step that I think defines all great talks: practice.