I recently gave a talk at the Philly XP meetup on how to use your version control data to find technical debt hotspots. It was the first tech talk that I had ever given. I’d like to talk about the process I used to come up with the talk, as well as some techniques for preparing to give the presentation.
Motivation
A while back, I read several books by Adam Tornhill that had some interesting ideas about how to do behavioral analysis on your codebase. While talking about these ideas to Nick Goede, a co-organizer of Philly XP, he suggested I give a talk about it. Without having much of an idea of what I’d talk about, I said yes and committed before actually having a talk put together. I believe this is how many talks are born. :)
Desired Outcome
The whole point of a talk is to share information with people. Out of respect for anyone who would attend the talk, I wanted to make sure that the talk would be worth their time.
I thought about what information would be useful to them and would enable them to run behavioral analyses on their own codebase in order to find their highest priority tech debt. I also wanted to show them tools to be able to actually do it and not just talk about things conceptually. Finally, I wanted to give them a few tips for addressing the tech debt once it was found. There are many books on the topic, so I limited it to a few common things that I’ve seen.
Coming Up With The Talk Material
I went back through the books that I read and put notes into a text file. I also used my own experience with running the behavioral analyses on my own codebase as material. As I wrote the notes down, I tried to group them by slide. Once I had a substantial amount of material, I translated the notes directly into the slides.
I know that it’s a bad idea to have slides that are full of text, so I trimmed down each slide to either have a phrase, idea, or image, and have each slide map to some of my notes in my text file. The notes are for my own reference, in case I forget something that I wanted to mention when talking about a particular slide.
The Slides
I tried to keep my slides as minimal as possible. The vast majority of slides had either an image or a several-word phrase that was relevant to what I was currently talking about. I had several slides that had bullet points on them. Most had two or three bullet points, although a few of them had four bullet points.
I had about 70 slides and got through the talk in about 35 minutes, so I’d say I spent 30 seconds on average on each slide. I think this helped the audience feel like the talk kept moving at a decent pace since there were few instances where I was on one slide for a long time.
Rehearsal
For rehearsing the talk, I had a 4-step process:
- Record
- Listen
- Tweak
- Repeat
Record
I recorded myself giving the talk on my phone using a sound recorder app. A number of sound recorder apps are freely available for iOS and Android.
Listen
After recording the talk, I would play it back and make notes about:
- Areas where I stuttered or blanked out
- Things that didn’t make sense
- Places in the talk where the flow wasn’t great.
Another benefit of being able to listen to my talk is that I know how long I took. This gave me an idea of how long my talk was going to be when I actually gave it.
Tweak
Based on my recording, I would add, remove, or reorder slides. I would also adjust my notes to reflect the changes in the slides. This would become the basis for the next iteration of rehearsing the talk.
Repeat
This was an iterative process. With every iteration, the talk would have more content or become more refined. I also memorized more of the talk and eventually got to the point where I didn’t really need the notes. At a certain point, it was just rehearsal and keeping things smooth.
Giving The Talk
Despite having the material down pat, I was still really nervous. I was afraid that folks would think that what I was talking about was BS and I feared having an argument with an audience member that would expose my ideas for foolishness.
I believe being nervous for giving a talk is normal. If you’re not nervous, you may not really care about the talk you’re giving.
Also, my fears were completely unfounded. Everybody was very respectful and at the questions section at the end, a lot of people had really good questions, which led to great discussion. And even though I thought that my talk was basically a rehash of a talk that Adam Tornhill gave, some folks at the meetup told me that, with some work, the talk could be a great conference talk.
The actual speaking part wasn’t too difficult for me. I’ve performed music and sang karaoke in front of people, and I’ve also moderated a reading group at work, so I have a level of comfort with addressing a group of people. I understand that other folks have trouble with this part, and that’s okay.
Just remember, your audience is here because they’re interested in what you’re there to talk about, so they’re with you. They’re not out to criticize you and tear you to shreds; they came to learn.
The piece that really helps is rehearsing. Rehearse, rehearse, rehearse. If you know your material, you’re less likely to blank out and get thrown off.
Conclusion
I highly recommend giving a talk about something you’re knoweldgeable or passionate about. You can help other folks in your community learn and grow. A full-length talk may be a little much to bite off, so maybe start off with a 5-10 minute lightning talk. After that, work your way up.
Through a great deal of the process, I dreaded giving the talk and thought it would be something I’d never want to do again once I gave it. I was totally wrong. I now feel like I want to refine the talk I already have, or work on several shorter lightning talks on other subjects.
References
Materials for my talk can be found in this GitHub repo.