For nearly ten years I avoided public speaking entirely. My last time at the front of a room had been in 2008, as a teaching assistant. The memory was not exactly a triumph.
Then I attended KCDC — the Kansas City Developer Conference — and watched a handful of speakers do something I wanted to do: take a technical idea, shape it into a story, and hold a room with it. I went home and signed up to speak at my local .NET user group, TRINUG. The talk: Get a Jump-Start on ReactJS.
What followed was six weeks of deliberate preparation, a 90-minute session that ran fifteen minutes over because the audience would not leave, and an immediate invitation to return the following month. Here is what actually helped.
Start With a Title and an Abstract
Before you build a single slide, write your title and abstract. This forces you to know what your talk is actually about — not the technology, but the argument you are making about the technology.
John Papa's Pluralsight course The Art of Public Speaking and Effective Presentations walks through exactly this process. What is the one thing you want the audience to leave with? Write that down first. Everything else is in service of that sentence.
A strong abstract does three things:
- States the problem or question your talk addresses
- Signals who the talk is for (beginners, intermediate, specialists)
- Promises a specific outcome — what attendees will be able to do or understand after
Keep it under 150 words. If you cannot explain the talk in 150 words, the talk is not ready yet.
Find Your First Opportunity
User groups are the best starting point — lower stakes than conferences, more forgiving of rough edges, and often actively looking for speakers on topics their members care about.
Where to look:
- Meetup.com filtered by your tech stack and city
- Your local .NET, JavaScript, Python, or DevOps community groups
- Company internal tech talks — the safest possible first audience
- Lunch-and-learn sessions at work
Once you have done two or three user group talks, conference CFPs (Call for Papers/Proposals) become a realistic next step. Sites like Papercall.io, Sessionize, and conference Twitter accounts announce open CFPs. Submit the same abstract you have already proven works in a user group.
Study How Good Speakers Work
Scott Hanselman's Pluralsight course The Art of Speaking (recorded with Rob Conery) is one of the most practically useful resources I found. It covers the full arc: research, slides, live code demos, delivery, handling questions. Hanselman is unusually honest about what goes wrong and why.
Complement this with the Microsoft YouTube panel featuring Hanselman, Kathleen Dollard, Dn Naggaga, and others talking about public speaking in the tech community. Watching multiple experienced speakers discuss the same topic from different angles builds a more complete picture than any single course.
Watch talks you admire and reverse-engineer them. Notice the structure: how does the speaker open? Where does the first demo appear? How do transitions between sections work? You are not copying — you are building a vocabulary of techniques to adapt.
Your Demos Need to Work
I practised my React demo at least six times before the night. Not six run-throughs — six complete sessions, including the parts where something goes wrong and you recover.
Live coding is the highest-risk element of a developer talk. If your demo breaks in front of an audience, the audience confidence in you drops sharply regardless of how technically excellent your content is.
Practical demo preparation:
- Have a pre-built backup version you can switch to if live coding fails
- Record yourself running the demo at least once — watching the recording reveals problems you miss while doing it
- Use Loom to record practice runs and review them without having to watch in real-time
- Test your font size from the back of the room — it is always too small
- Keep a terminal tab open with the completed code, ready to paste if needed
Building Your Slides
Slides are supporting material, not the talk itself. Your slides should not be readable from across the room — if they are full sentences, the audience is reading instead of listening.
What works well on slides:
- Single keywords or short phrases that anchor a point
- Code snippets (large font, high contrast)
- Diagrams that would take longer to describe in words
- One idea per slide — resist the urge to pack multiple points
Tools worth knowing:
- Canva has developer-friendly presentation templates and handles code blocks reasonably well
- Carbon.now.sh generates beautiful code screenshots if your slide tool handles syntax highlighting poorly
- Keynote and PowerPoint both work fine — the tool matters less than the content
Practise Out Loud
Reading through your talk in your head and saying it out loud are completely different experiences. The phrasing that reads smoothly often sounds stilted when spoken. Filler words you did not know you had appear. Transitions between sections that seemed obvious turn out to need bridging sentences.
Minimum effective practice for a first talk: say it out loud, from beginning to end, at least three times before the day.
Time yourself. If you are consistently over, cut — do not plan to go faster. If you are consistently under, the talk may need more depth or your pacing may be too rushed.
Mind and Body on the Day
Public speaking activates the same physiological stress response as physical threat — elevated cortisol, increased heart rate, heightened alertness. This is not a malfunction. It is energy. The question is whether you can direct it.
The practices that helped me most in the hours before:
- A short walk outside
- Deliberate slow breathing for five minutes before going in
- Going over the opening two minutes of the talk until they are completely automatic
The opening is the highest-anxiety moment. Once you are past it, the rest flows. Do not improvise your opening — have the first three sentences memorised so that your voice is steady before your brain fully catches up with the situation.
Handling Questions
Prepare for the three most likely questions before the talk. You will not be asked all of them, but thinking through them removes the feeling that the Q&A is entirely unpredictable.
If you get a question you cannot answer: "That is a great question — I do not know the answer off the top of my head, but I am happy to follow up after if you grab me." Then actually follow up. This response is more credible than a confident wrong answer.
If you get a hostile or very long question: "Let me make sure I understand — are you asking X?" Paraphrasing buys thinking time and often clarifies what was actually being asked.
The Online Speaking Shift
Since 2020, a significant portion of developer conference talks happen online. Some considerations specific to remote presenting:
- Your audio quality matters more than your video quality. A decent USB microphone costs less than a conference ticket.
- Energy and pacing need adjustment — without audience feedback, it is easy to go either too fast or to stall.
- Record every online talk. Use Otter.ai or similar for automatic transcription — the transcript becomes a blog post draft with minimal editing.
- Zoom, StreamYard, and OBS all handle screensharing differently. Test your setup the day before, not the hour before.
Offer Something After
At the end of my TRINUG talk, I told the audience that if anyone was working on their first presentation and wanted feedback, they could reach me on Twitter. Three people took me up on it that month.
Speaking is not a one-way broadcast. It is the beginning of a conversation. The most valuable thing you leave the audience with is not always the slide content — it is the sense that the conversation can continue.
Post your slides publicly (Speakerdeck is the standard for developer talks). Link them in the event description. If you recorded the talk, share the recording. The content you spent six weeks preparing should have a longer shelf life than one evening.
Pre-Talk Checklist
The night before:
- Slides on the presentation machine and backed up to USB and cloud
- Demo environment tested and working
- Backup demo code saved in a separate tab
- Presenter notes visible on your screen, not the projector
- Font sizes checked at distance
- Water on the podium
Day of:
- Arrive 30 minutes early
- Connect to the projector and run through the first three slides
- Find the bathroom, the clock, and the light switches
- Introduce yourself to the organiser
The Real Lesson
I waited nearly a decade to give that talk. The resources above would have been available years earlier. The only thing that changed was deciding to go.
If you are a developer who has thought about speaking but kept finding reasons to delay, this is the post telling you: the resources exist, the community is welcoming, and the ten minutes of discomfort at the start of your first talk is a very small price for what comes after.
Start with a title. Write one sentence about what you want the audience to leave with. Submit it to a user group. The rest follows.