How I sabotaged my own tech talk
Last Tuesday, I gave a talk on how to write REST APIs at my local webdev meetup. I’ve been a backend coder for years and write APIs all the time. Yet I still failed to teach the crowd and wasted everyone’s time.
I could have given a talk with no slides or preparation and it would have been better than the 80 pages of Keynote I threw together in a Fugue state. So why did it happen and how did I sabotage my own talk?
A litany of sabotage
1. The talk was too damn long
I did an outline and had a good idea of the four major topics I would cover. It was reasonable and I figured I’d end up with 20–30 slides. I finished slides for the first two topics, had a friend review it, and I was already at 30 slides.
The pages kept piling up and I fooled myself into thinking this was a Lessig style presentation and it was acceptable to have 80 slides in a scheduled 45 minute talk. I ended up skipping 10–15 slides and still went 20 minutes over my allotted time. I knew this was going to happen and even joked about it in a Tweet an hour before the talk started.
2. Too much backstory
People used to brag on the original Star Wars because it had a long exposition. Well that was 30 minutes out of two and a half hours. I ate up 40 minutes out of an hour long talk talking about the REST dissertation, a REST API style guide, and why ORMs are God’s gift to APIs. TBH, I could have cut the whole thing and had a pretty damned good presentation that started in medias res: easy to read examples of GET, POST, PUT, DELETE with real code.
Unfortunately, I opened by pummeling the audience with 10 slides on Roy Fielding’s dissertation on REST. I had never heard of Roy or the paper before I started prepping for my talk. A few other talks on REST mentioned the dissertation, so I thought it was important to read it. I was proud that I kinda understood it, so I thought it was a big deal to mention that the paper was a big deal. But I did not stop there. I laid ample foundation and showed how clever REST was by breaking down its architectural stylings.
3. I wasn’t an expert on my opener
I started my talk and introduced the REST dissertation, then read the “client-server” section and forgot of any non-obvious examples. Then I had nothing to say about “stateless”, got incredibly nervous and froze up for 10–15 seconds while thinking about what to say next. How could I possibly make it through this minefield without repeating these boring slides verbatim? I was in a temporal rift, where it felt like I had been standing in front of the audience in my underwear for 10 full minutes. I knew it was really not taking that long in real time, but it sure felt long when a few people got up and left the talk, never to return.
I definitely overcorrect in the “don’t read your slides” department. I had a teacher in business school who used to say “the only reason you should ever read every word on your slides is if your audience is blind”. It’s important to not recite every word, but that doesn’t mean you are playing a game of Taboo. You don’t have to ad lib 100% of the time. You just have to provide enough context for your audience to connect with the subject matter. And you can’t do that by summarizing a research paper that you learned about a day ago. If you’re not knowledgeable on a topic, don’t cover the foundation. Use analogies and tell your story. People did not attend the talk to hear a summary of a Wikipedia article.
4. I repeated myself
I violated Don’t Repeat Yourself (DRY), a sacred law of software engineering. I went over CRUD 4 times: once when covering REST API best practices, once in explaining ORM usage, once when discussing how routes work in Sinatra, and once in an example. My audience was a web devs meetup, so they had some familiarity with CRUD. I could have shown an overview table and jumped into examples and I would have been fine.
It is perfectly okay to give summarize your main points, but don’t repeat yourself. Your audience will either tune you out or worse, their understanding of a new topic is muddled.
5. Not Enough examples
I’ve heard and seen horror stories of live code. But fear of live coding is overblown. Most problems that people encounter can be solved in less than five minutes or flanked with a pre-built version of code. It benefits the presenter, since you don’t have to spend as much time polishing your examples. You’ll sidestep syntax highlighting in Keynote and you don’t have to heavily test your code examples. Plus you’ll save slides since your explanations will be in real time.
You also lose out on a communicating style and tooling. Showing examples of real code provides great insight into how code is used in the real world. For example, I learned about the magical spread operator (“…”) in @jchristianhall’s talk on Redux. In my live code, I get to tell people why I include pry and honeybadger in all my apps. Reading other people’s code is a great way to learn things ancillary to the talk.
6. Covered topics that were outside of the scope
As eager as I am to teach first principles, a tech talk is not a lecture. If the talk has many prerequisites that your audience MUST know, then the talk is probably not a good fit for your audience. If the the background is helpful but not required, include it in a additional resources slide at the end.
The goal of my talk was to introduce front end devs to API design in Ruby. I should have focused on mechanics from Ruby outward, rather starting at the creation of the universe origins of REST and best practices for REST API design. I also should have cut out the 15 pages on database design, since that is another tech talk in itself. Plus, adding all of these extras to my talk was false advertising. I’m sure that 45 minutes into my talk the audience was wondering, when is he going to show some Ruby.
