Conferences, user-groups, and internal speaking events are a great way for you to level up your career as a developer.

There are a lot of reasons behind this – the network effect of meeting like-minded peers is infectious and probably where your next job will come from. Reaching out into the community will help you discover things you never would alone or inside your organisation. Most importantly of all though - learning to explain a technical thing will help you understand it and literally make you better at your job.

This is all well and good, but if you've never put together written technical content before, the idea can be terrifying.

I regularly have conversations with people who would like to get into speaking, but just don't know where to start. They tell me they stare at an empty slide deck and just feel blank page anxiety , and often give up. I know seasoned veterans of the tech scene who still fight this problem with every new talk they put together.

Before we start, it's worth highlighting that there's not just one way to write a talk , no more than there's one plot structure to a movie or a book. I'm going to talk about a pattern that works for me.

All my talks don't follow this pattern, but most of them start this way before they perhaps become something else – and I'll dissect a few of my talks to show you how this process works on the way.

I can't promise that your talk won't suck by following these instructions, but hopefully it'll give you enough of a direction to remove some of that empty page anxiety.

What is a conference talk meant to do?

Conference talks are meant to be interesting; they are entertainment. It's very easy to lose track of that when you're in the middle of writing a talk.

We've all been in that session.

The room is too hot, and the speaker is dryly reading patch notes.

You want to close your eyes, but you can practically make eye contact with them you're so close and you just want it to be over. Time slows down. There's inexplicably still half an hour left in the session, and you just want to get out.

When you are finally free of the room, you turn to your friend, and in shared misery mutter "god I'd never write a conference talk this boring". A good conference talk entertains the audience, it tells a human story, and it leaves the audience with something to take away at the end.

You're not going to teach the entirety of a topic in an hour or less, accept this, and do not try to.

Your goal is to leave the audience with some points that they can look up** once they've left the room, and a story about your experiences with the thing.

That's the reason you were bored in that talk and just wanted it to end. It's the reason you didn't enjoy a talk by a famous speaker who came unprepared and just "winged it".

Conference talks are not the same as documentation, or blog posts, or even lectures.

Once you accept that the goal of a good conference talk is to be interesting and entertaining it frees you from a lot of the anxiety of "having to be really technical" or "having to show loads of code". Your audience doesn't have the time to read the code as you're showing it, but they have time to listen to you speak about your experiences with it.

The reason it's you giving the talk is often the most interesting bit, the human story, that's what people connect to – because if you were in a specific situation and solved that problem with technology, your audience probably is too.

Understanding your audience

There are four different kinds of people you will find in your audience.

1. The person who you think is your target audience.

They probably know a little about the thing you're talking about – perhaps they've tried the technology in your talk description once or twice and haven't quite had the time to work out how to use it. They have the right amount of experience, and your content will connect with them.

2. The person who is in the wrong room

This person might have come to your talk without really understanding the technology. Perhaps they're very new and your talk is aimed at existing practitioners. Perhaps they're interested in seeing different types of talks or talks outside of their main area of expertise. They're very unlikely to "just understand" any of the code you show them.

3. The person that is here to see code

There's a special kind of audience member who will never be satisfied unless they're looking at hardcore computer programming source code on a projected slide. You'll find them everywhere – they're the folks that suggest talks "aren't technical enough" because they often expect to see the documentation projected before them.

4. The person who knows more than you about the tech you're speaking about

This person already knows the technology you're going to cover, and they're here either to verify their own positions, or possibly because there wasn't another talk on that interested them, so they just went for something they knew.

Your job is to entertain and inform all of them at once.

You'll see these people time and time again in the audience – remember – they don't know if this talk is going to be for them until they're in the room, so it's your responsibility as the author of the material to entertain them all.

The four-act play.

An entertaining talk lets each of those different audience members to leave the room with something interesting that they learnt to lookup afterwards, and we can do this by splitting our talk into segments that satisfy each of those different audience members.

First and foremost, your talk is both a performance and should tell a story that people can connect to. This means we shouldn't just be pasting code into slide decks and narrating through it for the entire session - those deep dives work far better as an essay or blog post.

What works for me, is to divide talks up into a four-act structure.

• Introduction
• Act 1 – The Frame
• Act 2 – The Technology
• Act 3 – The Example
• Act 4 – The Demo
• Conclusion

Once you've got through the introduction – which is typically just a couple of slides to introduce the talk and help you connect to the audience, each of the "acts" has a purpose, and is sneakily designed to satisfy the different things people are hoping for in your talk.

Act 1 – The Frame

This is the setup for the entire talk, it's the hook, the central conflict, or the context that you're providing your audience, so they understand why you're talking about the thing you're talking about.

It's often about you, or an experience you've had that lead you to a particular piece of technology. It should contextualise your talk in a way that literally anyone can understand – it's a non-detailed scene setter.

In a recent talk I wrote about GameBoy Emulation , the frame was a mixture of two things – my childhood infatuation with the console, along with wanting to explain, at a low level, how computers worked to an audience. To explain emulation, I knew I needed to do a bit of a Comp-sci 101 session in hardware and remembering the things that seemed like magic to me as a child gave me a suitable narrative position to dive into technical details from. It made a talk about CPU opcodes and registers feel like a story.

Another example, from a talk I wrote about writing a 3D ray-casting "engine", my frame was the history of perspective in classic art. Again, because I knew that the technology part of the talk was going to talk about how visual projections were implemented in code, I was able to frame that against the backdrop of 3D in traditional art before leading into the history of 3D in games.

In both examples, the frame helps someone who might not understand the more technical portions of the talk in details find something of interest and hopefully of value to take away from the session.

Act 2 – The Technology

This is "the obvious part", once we've introduced the context that the talk exists in, we can discuss the specific technology / approach / central topic of the talk as it exists in this context.

In the case of my 3D ray-casting talk, at this point we switch from a more general history of perspective in art to the history of 3D games, and what ray-casting is.

You can go into as much detail as you like about the technology at this point, because this part of the talk is for the person who is your intended audience – who knows just enough but is here to learn something new.

I often find this part of my talks are quite code-light, but approach-heavy – explaining what the technology does, rather than how it does it.

Act 3 – The Example

Once we've introduced the technology, your example should work through how you apply it to solve a problem. This is often either a live coding segment (though I'd advise against it) or talking through screenshots of code.

Some people thrive doing live coding segments, but for most, it's a lot of stress, and introduces places where your talk can go badly wrong. Embed a recorded video, embed screenshots and narrate through them – pretty much anything is "safer" than doing live coding, especially when you've not done it before.

This act is for everyone, but especially people who feel cheated if they don't see code in a session.

Act 4 – The Demo

Applying much the same logic as the above – show the thing working. If there's any chance at all that it could fail at runtime, especially for your first few talks, pre-record the demo. Live demos are fun, and even the most veteran speakers have had live demos fail on them while on stage.

Don't panic if it happens, laugh it off, and be prepared with screenshots of the thing working correctly.

The Conclusion

The trick to making your talks seem like a cohesive story or journey is that you then use your conclusion to come all the way back to your framing device again from the start , to answer the question you posed, or explain how the technology helped you overcome whatever the central problem was at the start of your talk.

In my GameBoy talk, the "moral of the story" is all about it being ok to fail at something, and continue until you make progress, the difficulties I initially struggled in building a GameBoy emulator were part of the framing device and coming back to them ends the talk with a resolution.

Similarly, in my 3D rendering talk, the frame is brought back in again as I explain that throughout the process of building a ray-caster, I understood and could answer some questions that confused me about 3D graphics as a child, again, providing resolution to the talk.

While your talks will inevitably not please everyone in attendance, by taking the audience on a journey that they can take different kinds of learnings from throughout, it increases the chance of your talk going down well. This, as a result, makes the topic more memorable and relatable.

The slide deck

The empty slide deck is a real anxiety inducing nightmare – so the most important thing to do when you need to start writing the talk is just getting something into the deck. I like to imagine my slide deck as an essay plan – with a slide per bullet point.

You're going to want to create your slide deck in multiple passes, and to start with, just add slides with titles and empty bodies to get the main structure of your talk down on paper. You'll want to budget about 2-3 minutes per slide so split your talking points down quite finely.

Getting this first outline done in slides is the single most motivating thing you'll do when writing your talk, because once it's on paper, you no longer have to hold the whole talk in your head, and you can focus on filling out specific slides.

I generally avoid text in my slide deck instead using images that represent the concepts until I need to show concrete things like diagrams, code, or screenshots. This has the nice side effect of having your audience looking at you, and paying attention to what you're saying, rather than trying to read the text on the deck.

Once the main flow of your talk is locked in, leave it, and get on with writing your script – you should come back at the end once the talk is written, and make the slides look good. Trust me – it's easy to get distracted polishing slides before you finish your narrative, and you might find that the slides that you'd previously made beautiful will have to change as a result.

The script

If you ask people if they script their talks, you'll get a wide variety of responses – some people prefer to talk around their slides, others prefer to read from a script like an auto-cue, and I'm sure you'll find someone everywhere in between.

I script my talks to the word – every utterance, every seemingly throw-away joke, dramatic pause, chuckle, it's all in there. That doesn't mean that I always read my script in real-time – as you do your talk more frequently, you'll amend, and memorise it.

What a tight script is, though, is security. It protects you from illness, hangovers, your own poor life choices, literally anything that could get in between you and you doing a good session. Talks can feel robotic when they're read from the script without a speaker privacy screen, but if you make sure that you write your script to take the flow and rhythm of language into account – literally write it as you would like to say it – you can stop it looking like you're obviously reading a script.

While you don't have to use the script that you write, the act of producing the script is often as good as learning your talk , complete with the added protection if you need it.

The more technical your talk, the more you'll end up needing the script. It doesn't matter how well you know the topic, it's remarkably easy to fumble words when you're speaking and under the stress of being watched by an audience. It's ok, don't feel bad about it. Much rather you have a script than make a mistake and undermine a technical part of your talk.

Once you have your slide deck outline of your talk, you should walk through each slide, and write the script for that slide in the speaker notes of the slide deck. This way, when you're presenting, your speaker view will always have your script in plain sight. PowerPoint / Google Slides / Keynote all do this by default.

Do multiple passes , make sure the script still works if you re-order slides, and make sure that whatever you write in the slides fit into your 2–3-minute budget. Some concepts will take longer than that to explain but it's worth chunking larger topics across multiple slides. It's a useful mental crutch to know that you're keeping good time.

Remember - you do not have to use your script, but your talk will almost certainly be better if you have one.

Knowing what to talk about

Often the hardest thing to do when you're starting writing conference talks is even knowing what you want to talk about.

Consider these three questions:

1. Is there something you did that lead you to reconsider your approach or opinion?
2. Is there something you've worked on where the outcome was surprising or non-obvious?
3. Is there something you absolutely love?

The things that surprise you, or made you change your views on something are all good candidates for first conference talks. If you love something so much you must talk about it, then the decision makes itself.

If you're still lacking inspiration, you can check user groups / Reddit / Quora / LinkedIn for questions people commonly ask – if you spot a trend in something you know the answer for, it could be a good candidate to tell your story in that context.

There's no sure-fire hit for picking a topic that people will want to watch at a conference, but in my experience, enthusiasm is infectious , and if you care about something it's probably the thing you should speak about to start out.

Summary

You can never guarantee that you're going to write a talk that everyone is going to love but following this structure has worked for me and many of my talks over the last 10-12 years of public speaking.

One size doesn't fit all – and there are plenty of different talk formats that I utterly adore, but if you're struggling to get started hopefully some of this structural guidance will help you on your path to write better talks than I ever have.

Good luck!