The Ultimate Guide To Memorable Tech Talks — Part 2: Choosing a Topic and a Conference

Selecting a conference you’d like to speak at, and a topic you’d like to speak about.

Photo by Amy Shamblen on Unsplash

This is Part 2 of a multi-part Guide to Memorable Tech Talks. Visit the outline for more information.

Key Takeaways

1. Everyone, including you, has something interesting to say. Use everyday inspiration to pick a topic.
2. Choose a topic that you’re passionate about. Your enthusiasm will show.
3. Keep up to date on open Calls For Proposals at conferences you’re interested in. They typically end several months before the conference.

“I have nothing new to say, it’s all been covered” is a myth that I hear beginners perpetuate as a way to talk themselves out of speaking.

It’s not true. What an audience is genuinely interested in is your unique perspective, your story, and the way you tell it. Storytelling is as much a part of a great talk as technical knowledge. People are interested in the technical roadblocks you ran into and how you solved them. A confounding bug you came across, how you solved it, and everything in between is also a noteworthy topic.

If you originally found something confusing but you’ve made great strides in learning it, consider covering the concepts that helped you learn. Can you distill the Aha! moment you had when you finally figured it out and turn it into a teachable moment? Pick something that you’re passionate about, and it’ll show. If you’re forced to present on something that you’re not passionate about, try to find an aspect of the topic that you care about deeply, and see if you can get away with focusing on that.

Think clearly about your motivations for why you want to submit a conference talk in the first place. You can have a variety of reasons, but knowing what they are will help you define why you want to take action. You may want to improve your public speaking ability, boost your career, or stand on a soapbox for 30 minutes to teach and share your ideas. Those are all valid reasons.

What follows are stories of how I identified interesting topics that I wanted to share with a larger audience.

My motivation is usually selecting stories I want to share, explaining technical concepts, or describing processes I’ve seen that work well (or not) from my twelve years of industry engineering experience. For example, my Code Review Skills for Pythonistas talk idea came from a conflict in a workplace with a toxic culture. I temporarily joined an engineering team to help with an upcoming deadline. When I submitted my first Pull Request to that project, a junior engineer left 50 unhelpful comments on my short submission mostly centered on how much whitespace I left in my unit tests and how they were arranged.

I was left to figure out the mystery of why he felt strongly enough to leave dozens of comments on a valid PR. I learned that his old manager had instilled a collection of strict rules on how his old team should write their code and unit tests. His old manager no longer worked at the company. When I asked this engineer for a style guide or any documentation for his proposed changes, he linked me to a style guide in the ex-managers personal GitHub repository made of rules that mostly applied to Ruby, not Python.

Apparently, his firm assertion was based on a style guide that his old team followed at the company, but no other teams did. When I tried to talk with him in person about his behavior and motivations, and see if we could come to an understanding, he reacted by getting defensive and waving a copy of the Clean Code Book in my face, as if I had never read it before. (Side note: managers, please do not keep employees with toxic behaviors around and make excuses for them, no matter how productive they appear to be. They destroy morale!)

That situation, one of many unpleasant ones I’ve dealt with in my tech career, left my confidence shaken. I knew that the code reviews I had done at my old company were not a horrible combative process, and I had successfully introduced code reviews to other teams at organizations I’d worked at. I decided to codify what I had learned about doing constructive, positive code reviews (drawing on my experience from a role at a tiny startup named Modest).

I thought about the techniques that worked, the ones I always implemented, and the tools that I used to do the job. I also did a ton of research and read case studies and research papers. Once I was able to organize the ideas I knew really worked, I was able to put them into a talk.

The talk outlined how to be a good PR submitter, a good reviewer, went over the proven benefits of review, covered the process for setting style guides and standards, and outlined the Python-specific tools that help make the process a smooth one. As I’ve learned more, I’ve modified and changed the talk. Each iteration is an improvement. I can take the feedback I’ve gotten after each session, and apply it to my proposal for the next conference I want to give it at.

I came across the idea for my Memory Management in Python talk as I was learning about the topic. Every single resource I came across was overly complicated, obtuse, and assumed a lot of prerequisite knowledge on the readers part. It used dry, complicated terminology. The overall concept of how memory management in Python works is relatively simple, and understanding it can help even novices better learn and master the language. I took the topic and distilled it down into the simplest necessary concepts that I could cover in 25 minutes. The idea for my Elegant Solutions For Everyday Python Problems talk came from a few of the intermediate features I learned about in Python over the years that made me think “wow! that’s cool”.

The next talk that I’ll be doing is at PyCascades called Light Up Your Life — With Python and LEDs! on programming hardware and LEDs with Python. Working with hardware has turned into a passion project of mine for the past few years, with projects such as these Python-powered earrings.

I do my best to set myself up for success by speaking about topics that I’m interested in or passionate about. That energy comes through in my speaking and helps engage the audience. I suggest that you do the same. Consider a topic about technology that makes you feel excited, or about a technology that you love learning.

Selecting a conference to speak at is just as important as selecting a topic. You can select a conference based on your interests, your technology focus, or other factors. I love PyCon US because my primary engineering focus is Python and it’s the largest gathering of Python enthusiasts worldwide at 4,000 attendees. I’ve gone to several smaller community-run conferences like North Bay Python and DjangoCon US because they offer a supportive environment of around 400 attendees. I attended AlterConf based solely on word-of-mouth because I heard rave reviews from previous attendees.

Regardless of which conference you choose, you’ll need to submit a proposal for your topic which is covered in the next section.

Continue to Part 3: Writing a Conference Proposal (or CFP)

Skip to:

1. Introduction — About me and my journey through technical public speaking.
2. Choosing a Topic — Selecting a topic you’d like to speak about.
3. Writing a Conference Proposal (or CFP) — A guide to writing and submitting conference talk proposals.
4. Tools of the Trade — Tools for brainstorming, creating slides, time-management, and more.
5. Planning and Time Estimation — How to plan your preparation time before the conference.
6. Writing a Talk — Writing an engaging talk and captivating slides.
7. Practice and Delivery — Preparing for and delivering on the big day.