Hey Sole, you have spoken on a lot of places and go to a lot of conferences, so maybe you have some advice on how to write a talk?
Yes, indeed I do! In fact, this question comes up so often that I figured it would be super useful to share my method with more people, rather than just individually 
Before we start, allow me to highlight that this is my method, and it might not suit you. Talks come in many formats and shapes depending on their content, the audience and many other factors. I usually talk about technical stuff, and this guide is about writing that type of talks.
Also, if you’re the TL;DR type, I made you a flow chart (using draw.io):
Step 1: what do you want to talk about?
The first thing you need to figure out is your talk topic (unless you’ve been tasked to talk on a specific thing by someone else, in which case you probably can skip a few paragraphs ahead 
).
It might sound obvious, but you should talk about something you care about. Otherwise you’ll be bored when giving the talk and also bore your audience. We don’t want this.
Related, if you want to talk about a topic someone else has talked about before, what can you add? What’s your unique take on the subject? What do you know that they don’t? What do you know that the audience needs to learn about?
If you’re unsure whether someone has already talked about this, do a search! Many conferences record and publish the talks in their website for the benefit of the community. You can watch existing talks and see if you can complement or even improve them.
Don’t get discouraged if talks about your favourite topic exist already. Generally speaking, no one should claim exclusivity on a topic, and in fact, the more points of view we hear about a topic, the richer we will be. Also, think that if an idea is good, it deserves to be spread and debated about all over the globe. One monopolistic guru won’t do any good for the cause. So keep your idea in mind, and move on to the next step!
Step 2: the elevator pitch
So you have a more or less nebulous idea in mind. Let’s get to work!
Describe your talk in one or two sentences.
Does it sound interesting? Would you want to listen to this talk? Send it to your friends, co-workers and perhaps even other speakers. Sometimes you could even “test the waters” in Twitter or similar, by asking something like: “Would anyone be interested in a talk about XYZ? I’d cover A, B and C”
How’s the response to your pitch?
Do people absolutely want to watch this talk? Or is it more like a tepid, polite response, than an enthusiastic “yes please tell me all about this, I need to know already”?
If you pitched your idea in an actual lift, would they just say “oh, interesting” and then leave, or block the door when they reach their floor, and make everyone else wait for the lift because they want to hear more about your idea?
If your pitch didn’t get people excited, don’t sweat it. Practice: turn your idea into a blog post. You don’t have a blog? Open one. Write your thoughts down. Get feedback on the post. Send it to friends. Ask them what do they think.
Perhaps your proposal was confusing, and by writing the post you clarify your thoughts, and can come up with another rehash of your idea.
Perhaps you were focusing on the wrong aspect, and someone will casually comment “ah, I don’t really care that much about XYZ, but I’m curious to hear about the way you integrate XYZ with your existing infrastructure”. BAM! You found the topic! Try to turn this into a new elevator pitch, and repeat the process until both you and people get excited about your idea!
Perhaps it’s actually not interesting. This is fine too—maybe you want to submit your idea to Boring Conference, and yes, this is an actual thing! See? All sorts of ideas have a place in the world.
Step 3: outline
Suppose you hit a nerve and you have a topic that people care about. It’s time to expand the pitch into an outline!
Write it down in bullet points. Use the simplest thing you can get away with. I like to use a simple notebook (yes! real paper!), but a plain text editor is also good.
Do not use Keynote or Power Point or anything fancy, as you’ll get distracted with stuff which is irrelevant at this point, such as font colours and slide designs and what not.
Follow a simple structure. Something like this:
- Here’s this problem I had, this is why it’s a problem
- One (or more) of this:
- Other people had tried this
- No one else had this problem
- No one else could fix it
- TADA! This is how ✨I / my team / someone I admire✨ fixed it
- Advantages of doing this versus other solutions
- My life is now so much better thanks to this
- Wrap up
- Links and pointers to further resources
- Thank everyone
Sometimes you might get random ideas that seem related but are not quite there. Write them down and shuffle things around until it makes “linear sense”. You’re not writing a novel with flashbacks and sudden revelations here. You are writing a talk. Make it easy to understand and follow.
If your ideas are really all over the place and you can’t figure out what you’re doing, it can help to write each topic on a sticky note, and physically shuffle things around until you can see a logical progression. You might even find connections you didn’t notice before! Or if you’re feeling very adventurous, use normal non-sticky pieces of paper and shuffle them around and see if something interesting emerges from the randomness!
By moving pieces of paper around you’re able to focus on the concepts and the relations between them, and not the text editor autocompleting, or saving the file, or your computer crashing, etc.
If I don’t have stickies nearby, I will find some scratch paper (something I don’t mind destroying afterwards) and scribble all the thoughts with enough spacing between them, then start drawing arrows and circling important stuff, and connecting things, striking out less important things, etc. It ends up being a mess, but helps me to understand what I am thinking about. No one else needs to be able to decipher your scribbling—this is only for you!
You’ll be surprised at how well this works!
Step 4: step away and come back later
Once your outline is ready, save the text file, close it (or alternatively hide it on a drawer), and don’t look at it for a day or two. Or a week!
Then look at it again. Does everything still make sense? When you’re working on something for hours it’s very easy to get familiar with it and overlook errors that are right in your face.
Fix what doesn’t make sense.
Do you still like this talk idea? Good! Go to the next step. Alternatively, try to reconsider why you don’t like it anymore. Is there anything you can salvage? (there usually is). Rewrite, rewrite, rewrite.
Step 5: send outline to friends
When you’re happy with the outline, send it to friends and ask if they would like to watch this talk.
It helps to have a diverse group of friends to get a variety of opinions. Conference attendees have various levels of topic understanding, and it’s great if you can give everyone something to take home, even if they don’t understand everything.
For example, it pays to send it to someone very knowledgeable on the matter, as they can give you advice on things you are maybe missing, and then also send it to someone who is totally new, as they can tell you if the outline sounds absolutely impenetrable.
At this point you will get feedback along the lines of “this progression is not clear” or “I’d like to hear more about this point” or “this doesn’t seem important to me”.
Act on the feedback. Make corrections. Read it aloud. Is there a good logical progression? Does it flow? Are concepts presented in a meaningful order? Remember: we’re not writing an experimental novel that travels back and forth in time. People at conferences can be distracted. Make it easy for them to follow your thoughts. Is it gentler for newbies now? Are there good take aways for experts? It’s about the balance.
Send it to people again and see what they say.
You don’t need to agree 100% with them – it’s OK to disagree. Use your instinct! Perhaps the world is ready for a more intense talk on this subject!
Repeat these steps until you’re happy with the structure.
TIP: I usually put my talk outline on a private gist on GitHub so friends can leave comments in place, which is useful to avoid various people pointing out the same fact in private channels. Saving friends’ time is great!
Another thing you can do to validate the idea before actually writing the talk is to submit the talk as a proposal for a conference. You can take the outline as a guide to write a couple of paragraphs for the abstract.
If you get accepted, you get an official proof that your idea is interesting! (this is a part of what I jokingly call “conference driven development!”). (I also wrote a bit about how to be successful on conference proposals).
Step 6: writing the talk
Either way, it’s finally time to write the talk.
And we’re going to do it by expanding the outline.
Open a new text file and copy and paste the outline contents on it. We’re going to turn it from this:
* Concept 1
* Concept 2
* Concept 3
Into this:
Concept 1
Paragraph describing concept 1
Perhaps another paragraph
Concept 2
Paragraph describing concept 2
Perhaps another paragraph
Perhaps even another one!
etc…
Roughly, each concept will translate to one slide. Write what you would say when each slide is shown, and read it aloud.
If anything sounds “weird”, i.e. unnatural or something you would not say when talking conversationally, remove it or change it into something else. For example: if a sentence is too long, shorten it, or split it into shorter sentences. Or if a paragraph introduces too many things at once, it might be confusing. Split it into other paragraphs and have one concept per paragraph (this might add additional slides to your presentation).
Also check for continuity inconsistencies: does the previous section lead to this one? Are you suddenly introducing a totally new concept out of nowhere? This is going to confuse people. Watch out for this!
You want this text to sound like you’re talking to a friend; there’s no need to use pompous language. We’re aiming for conversational prose.
Step 7: timing
When you finish expanding the talk, read it aloud again. From the beginning, with natural pauses and speed, just as if you were talking to a friend—but also timing it.
You need to make sure that your talk won’t go overtime. E.g. if the conference asked you for a 30 minute talk it’s a tremendous sign of disrespect to take 55 minutes—schedules are usually very hectic already, and you’ll just be putting additional stress on everyone (apart from looking really unprofessional).
You don’t need anything fancy to track how long it takes you—a normal watch is fine, although most phones nowadays have some sort of chronometer functionality.
If you’re on time, great! You’ve got this! 
If you’re not, it’s time to cut things out. You might not know what to leave out, so take your time and re-read everything a few times until you notice something that might not be essential for listeners.
Some examples of things that usually find their way into talks but could probably be cut out:
- long lists of bullet items. No one likes to hear someone read aloud a long list, unless you want to create some kind of dramatic effect. Keep the top three items, and replace the rest with “…”.
- sideline digressions, where you depart from the main topic to mention something anecdotal. This could be OK for a blog post, but in a talk it can take a few of your precious minutes, and make you lose momentum. You don’t need to totally forget about this material—just strike it out or cut it out and keep it just in case you write a post!
- when showing source code, you don’t need to show a complete working example. Show a fragment instead.
- again, when talking about code, you don’t need to explain what each line and keyword do. Focus on the trickiest aspects only, and let interested parties either figure out the rest or ask you after the talk.
Pseudocode is your friend. Don’t worry about the syntax. You’re often talking about logical concepts rather than syntax accurate fragments. Turn blocks of irrelevant code into pseudocode. E.g. a 10 line block to do an API call and processing results could be summarised into doAPICallAndGetResults().
It’s OK if you have more material in your head than can fit in the talk. This is never bad. You can’t help being knowledgeable!
What you can do is ask the audience and test their background on the topic before you start. If they know more than you expected, you can omit some of the basics you prepared, and spend a little more of time on additional details. By contrast, if they know less, you know there will be no point in mentioning lots of details and it’s more important to provide them a clear introduction.
And if you get asked a question, the more you know about the subject, the more chances you have to answer it.
Audiences love when a speaker is able to accommodate their needs. It shows that you truly know your stuff.
Step 8: finally making slides
We’ve finally reached the point that many people associate with writing a talk. It just took us seven steps!
Here’s where personal preferences get in play. You’re free to use whatever you like to create your slides, as long as you’re comfortable with the process and with using the slides in stage.
Remember that slides are just meant to help you present. You might not need slides. Professors have been giving masterclasses without slides for centuries, way before PowerPoint was even invented. I’ve presented without slides. Other people have too. It’s entirely possible.
I like to use HTML based slides, because I talk about browser APIs and I like to show built-in demos without ever leaving my slides, as I think this helps in getting a better flow. And I also despise clicking on buttons to obtain effects and create things that I can create faster with code. Hence, I stick to a somewhat spartan HTML based slide deck in which I’m in control.
Whatever system you want to use, it’s time to go through the write up and create one slide per concept.
Unless you’re showing source code, you should show very little text on the screen. The slides are there to help you present, but they are not the end goal here. A slide deck does not a presentation make.
TIP: if a word is hard for you to pronounce because you’re a speaker of English as a second language or because it’s a weird word in itself or a new unfamiliar concept that very few people have heard about, put it on a slide and ‘say it’ as the same time the slide is shown on the screen, so people will connect both in their minds.
Most professional presentation software and some HTML based slide deck systems allow you to add speaker’s notes. I’m a weirdo that memorises the entire talk, so I don’t use these, but if it would make you feel more confident, you can take the paragraphs from the write up and enter them into the software. You already worked hard in making them sound conversational, so if your mind goes blank while presenting you can use them to “save you”.
TIP 2: speaker’s notes and write ups are fantastic material for blog posts. Specially if you have a picture per slide, people love that format as it’s a very nice visual rhythm and easy to read. And some people don’t like to watch talks, but they do love to read blogs. Each person learns in a different way! For example, Maciej Cegłowski (founder of Pinboard) posts lots of write ups following a more tabular approach to this format, like this: The website obesity crisis.
Step 9: practise, practise, practise
Take your slides and your demos and set the timer to zero again. Practice while timing yourself, and make minor corrections if need be. You have already done a lot of work already, so you probably won’t need many adjustments now, but it’s always good to run through the talk three or four times.
Pretend like you’re already giving the talk in the conference. I like to stand up just as if I was in the stage—it makes me more aware of time passing than if I’m sitting down, and it also makes my “speaking persona” kick into action.
If you can, make a test run the talk with your colleagues, perhaps a lunchtime ‘brown bag’. Or maybe in a local meetup or user group. Or record yourself—webcams are ubiquitous nowadays.
Then apply any feedback you get. And don’t be too harsh with yourself. Don’t take advice as an absolute fact, but rather place it within its own context. For example: people in your office might not be the same target as the audience of the conference, so you might need to take their feedback with a pinch of salt.
If you give the same talk several times in different places to different people you will get different responses. But eventually themes will surface, and they will help you improve the talk by clarifying stuff that looked fine to you but confusing to everyone, or omitting aspects people don’t seem to care about, etc. Sometimes I practice “presentation A/B testing” when doing test runs of talks trying an slightly different approach that I’m not entirely sure would work or not, and then use the feedback from the experiment.
It’s all about practising, listening to your listeners to check that your formula is working (or not), and adjusting accordingly.
Step 10: SUCCESS (!!!???)
I hope these techniques can help you. I probably forgot something that you’re deeply curious about. Please ask me questions and I’ll try to answer them where possible. Also note this is only about writing a talk. I have had questions about how to deliver the talk. I will try to answer these in another post.
And of course I’ll be happy to hear about success stories too! If this helped you, I’ll appreciate links to it
Appendix A: Help! my slides look ugly! ![😩]()
This could be an entire post on itself, but let’s try to work on some emergency palliative measures.
The most important thing is the content i.e. what you talk about. You don’t need funny slides with fancy colours and cool GIFs if your presentation is interesting.
If you have absolutely no idea about design or no confidence in your aesthetic skills, just use a template. It’s absolutely fine to use templates. I just gave you permission.
If you’re using a template, don’t introduce new styles; keep using the predefined styles. This will help you keep the presentation homogeneous. Too much variation can be distracting from the content.
You can get templates from many places. Most presentation systems come with their own templates. If you work for an organisation you can probably get templates from the designers. They’ll be pleased that someone wants to follow the style guide!
If you’re feeling creative, and want to modify one of the existing templates, but don’t quite know how to do it, you could start by changing the typefaces or the colours in the predefined styles.
For typefaces, it’s good to search for “font pairings”. Altruistic designers have already done this work for you and published their findings online. You will find collections of fonts that work nicely together—for example, font A for the headers, and font B for the body text. Here’s an article explaining font pairings and other typographical concepts really nicely. It also has a good list of pairings. Font Pair is a tool that lets you play with pairings and copy text interactively using typefaces from Google Fonts.
If you change the font families, you might also need to adjust parameters such as font height, and margin and paddings of the default styles to make sure things are aligned and fit on the slides, so some light reading on white space, line height, letter and word spacing and other essential graphic design concepts will help you get a better understanding of why these adjustments are required (it will also help you empathise with your fellow designers 
).
TIP: If using HTML based slides, I suggest you make sure the font works offline where possible. I have seen so many cases of presentations looking awkward when the CDN failed to load under conference WiFi and the slides were rendered with a default typeface.
You can also play with colours. There are many websites where people who adore colours share their favourite palettes. For example: Cooloors or Colourlovers. Remember to give credit to the author of the palette you use!
Also: please don’t mix and match colours from different palettes. Remember that you’re using pre-picked palettes because you don’t know what you’re doing. If unsure, show this to friends, or even better, to a graphic designer.
Whatever you use, make sure the text is big and has good contrast. You don’t know how disastrous the projector or the screen are going to be. Maybe the image is blurry, or there’s barely no contrast. Bigger and contrasted text won’t solve these issues, but will alleviate them. These articles are loaded with good advice: Choosing a presentation colour scheme by Rebecca Murphey and A white label slide deck by Alice Bartlett.
Appendix B: Help! My presentation is not funny. How do I make it funny? Alternatively, how do I become funny?
Ah, the classic question: to joke or not to joke?
Or, in other words: do you want to be respected and trusted because of your technical prowess, or do you want to be a comedian?
Being a good comedian involves a lot of hard work, and after a while everyone will know your jokes (because the talks are recorded).
Don’t pressure yourself into “being funny” just because you’ve seen other speakers tell jokes. You need to develop your own style. If you’re not naturally inclined to be funny, there’s no need to suddenly start now.
Also, if you’re not careful, you easily risk offending people. And as technology involves so many areas of life, you have to be very careful. You don’t know who’s in your audience.
It’s better to restrict yourself to talk about tech. This is what you know about, and it will make you feel confident, which makes the audience relax and pay attention to you. In contrast, if you fake being funny, people can tell. It is terribly uncomfortable for everybody. Please don’t make us cringe.
This does not mean you cannot show funny stuff in your presentations. Errors and glitches can produce really entertaining results and are also truly a part of what makes programming joyful! And best of all, you won’t offend anyone with these.
For example, I showed how rounding errors can cause some weird effects on my simulated skeletons and they eventually end performing a sort of unexpected Saint Vitus dance in this talk. I didn’t need to tell a joke. It’s just the effect of the error itself that is hilarious, yet everyone was cracking up, and I didn’t need to offend anyone.
Good luck and happy talk writing! 
