5 Ways to Make Your Tech Talk Awesome
Over the last 2.5 years, I have become a bit of a tech talk connoisseur. Wherever I can go to one — at work, a SF meetup, a conference — I do. Tech talks are a great discovery mechanism: while Googling a topic, you’re usually looking for some specific information to help you complete a task, but a tech talk could be unexpected and completely new information, with a personal connection that you just don’t get from Medium or Stack Overflow.
Having just completed my last tech conference of 2018, I put some thought into what made my picks for the best sessions effective and generally awesome. I’ve avoided the advice you’re probably heard 100x before (be confident! practice! don’t say “um” or “uh” too much!) and stick to things that are especially relevant to tech talks.
Tip #1: Live code only if absolutely necessary to make your point
Live coding is awesome if you’re showing a small amount of code with a big impact. Otherwise, the stress it creates for you and for me probably isn’t worth it.
Before you add live coding to your presentation, consider how it is truly additive. Understanding what a snippet of code is doing and/or seeing it run is a better use of the audience’s time in the context of a technical talk than watching you type.
Some people have used live coding really effectively. Kelsey Hightower’s 2017 PyCon keynote was the best use of live coding that I’ve witnessed, including some humor when things momentarily didn’t work as expected.
Another great example of effective live coding is every talk I’ve seen my Raymond Hettinger, where he explains a concept relating to how Python works then demonstrates it with simple examples in the terminal.
If “live code” is a must, I recommend using Jupyter Notebook. Being able to uncomment and run code without typing is a good compromise and will save you and your audience some stress, and it’s a great resource to post online for attendees. This is a good segue into tip #2…
Tip #2: Have a short, easy to remember URL link to the relevant resources
People will want to look at your repo or slides after the talk — make it easy for them.
Have you ever put a url like this pointing your audience to the slide deck or repo for a talk?
http://example.com/your-name/projects/2380DGASJKA/conference/170415.php
This is hard for your audience to remember or type. Help us by using a url shortener like bit.ly or goo.gl and customize it with words I can remember so I can find the materials you worked hard on putting together. Yes, I can take a picture if I’m close enough to the screen but I still have to type it.
More often than not, this lengthy URL is on screen for 3–4 seconds at the very beginning or very end of the presentation. Which brings me to #3…
Tip #3: Put your contact info and links on every slide especially if your screen name is not your real name
Put that info on every slide and get the kudos you deserve!
When I’m watching a good talk, I often think, “oh! I should give this person some praise on Twitter/star their repo”, then realize I have no idea what their handle is, then get distracted for a couple of minutes while I try to find it. If I can’t locate the right person with a couple of searches, I give up. How am I to know that John Doe’s screen name is C0deW1zzerd83 with a picture of Leonardo from Teenage Mutant Ninja Turtles as his avatar?
This is another place where flashing your info on the first or last slide for a few seconds won’t do anyone much good. If I decide I want to follow along with your code 3 minutes in, or tweet how great you are, I’d be out of luck.
Tip #4 : Your constructive enthusiasm to rant ratio should be at least 3:1
Naming problems is useful, ranting without a goal or solution is not.
To quote The Simpsons, “It’s easy to complain…and fun too” (and to quote me, “pretty much everything about software development is messed up”). Snark and rants are a staple of every software engineering event I’ve been to, but before you engage in that, think about how additive that kind of theme is to your audience.
Snark/rants are often a way to commiserate or reassure folks they aren’t alone in their frustration. That’s awesome! But lengthy therapy rants aren’t always helpful from a conference stage; think about how you can wrap it up with a call to action and invite people to talk with you afterwards for an old fashioned snark fest if you still need to vent.
The best talks I’ve seen are by people who really care about the community, their coworkers and the industry. I don’t need to know them personally, it just shows. Critique is balanced with energy and enthusiasm for making things better, and I leave feeling energized and empowered rather than sarcastic and grouchy.
This is something I’ve grappled with in my talk about detecting gender bias in the Harry Potter series with Python. I really enjoy the books, and I have no doubt J.K. Rowling didn’t intend to write Hermione in a negative or biased light, but she did. But my talk is a critique of the work, not Rowling, it’s backed by data and a methodology anyone can read and send me feedback on, and I encourage them to try themselves on other works. My call to action is not for Rowling, but for the audience to consider how subtle messages for underrepresented folks permeate their language. I’m not sure that’s the best way to handle it, but that’s the best way I’ve come up with.
Tip #5 : Gift your audience a clear takeaway that isn’t about you
The best talks keep me thinking long after they are over about the content, not the speaker.
If your audience walks away from your talk saying, “wow, such-and-such library they presented on really doesn’t meet our needs we need to pick something else”, that is a win — they have useful information they didn’t have 30 minutes ago. If they walk away thinking, “wow, that person’s gif game is strong but I have no idea what they said”, that’s not the best result.
When you plan and give your talk, consider how you can get the audience to a new place of understanding or decision making. Some examples — your talk could aim to do one or more of these:
- Deciding something might meet a need for them or absolutely doesn’t
- Understanding a concept they weren’t familiar with before
- Thinking about something they haven’t previously considered
- Reconsidering or revising a previous opinion about a piece of tech, the industry, their team or beyond
A good example of this is Hayley Denbraver’s talk about engineering ethics (full disclosure: I know Hayley personally) that leaves the watcher with some clear considerations — comparatively new to many software engineers — about how they work and ask of others.
Another one, along the lines of ethics in software development is Caleb Thomson’s “I Built Software to Kill People” talk from Codeland. Even though it encompasses his personal story, it’s memorable because of the message he repeats again and again “but don’t get distracted by that, the software was built to kill people”. I walked away thinking about how I could ensure that my work isn’t doing harm. Win for Caleb’s talk.
None of this is to say your tech talk can’t be entertaining (please make it fun!) but if it’s just entertaining and not informing, it’s a different kind of talk.
—
To sum up my tips for a great tech talk:
#1: Live code only if absolutely necessary to make your point
#2: Have a short, easy to remember URL link to the relevant resources
#3: Put your contact info and links on every slide especially if your screen name is not your real name
#4 : Your constructive enthusiasm to rant ratio should be at least 3:1
#5 : Gift your audience a clear takeaway that isn’t about you
Giving tech talks is hard. I hope these tips are helpful in preparing your next one. And, thanks in advance for taking the time to share your knowledge with the community. ❤️
