Giving technical talks — tips to make your listeners happy

Font size and amount of content: This is the most crucial setting for your slides. It doesn’t depend as much on the room size as you think, as larger venues are often equipped with large canvases or even mirrored ones for the people in the back. Large font sizes are equally important for any room and any audience. If you don’t set a reasonable size when starting to work on your slides, you will 1) later have to reorganize your slides on font size increase because the content will not fit anymore, or 2) get the resentment of the audience when having to change it during the talk. The latter case is much worse, and I have seen many speakers use reveal.js and other web-based presentation frameworks without understanding how to use them. I even saw a presenter who understood at second zero of his talk that font size was way too small, asked the rhetorical question, tried to use the browser zoom feature, but failed at the attempt because the framework generated HTML that only zoomed controls, not font size. In such a stressful situation, you probably wouldn’t think of hacking it using Web Inspector to enforce the size change.
I can understand that PowerPoint and foes are not very helpful when it comes to syntax highlighting or embedding source code from a file, but yet you have to know what you use and come prepared. For static content, LaTeX presentations are a good starting point.
In summary: know your room and presentation target as you would know your deployment target when developing software. Just because it looks good on your screen does not mean people can read it with a projector (which by the way are usually 4:3 or seldom 16:9). Think of font size, foreground and background colors, contrast, limit font family and size variations and keep examples and text readable. That applies to slides, examples and also applications you switch to (terminal, IDE → zoom feature).

Colors: mind the color blind. I admit to have little knowledge around this, but if you tend to distinguish meaning by color, consider using something else instead (bold/italic/underlined text, side-by-side comparison table, multiple slides… depends heavily on content).

Hobby projects: At developer conferences, I noticed that speakers are often a mixture of: 1) experienced speakers who prepare well, probably even held their talk before in a smaller group and chose their topic based on either strong interest for a programming language, technology or standardization, or out of a real (business) use case/issue they encountered. 2) People whose name you didn’t hear before — often those basing their topic and slides around a personal problem statement or hobby project.
While a personal topic can be very interesting (I’m a big fan of lightning talks which have a lot of such topics), some topics are also very boring or useless for an audience that paid to learn about new standards, technologies and practices instead of a hobby project with questionable future, public interest (e.g. GitHub stars) or substantiated problem statement. Before even starting to work on slides or publishing something, check if it may be interesting for others. Key deliverables in that kind of presentation could be: real use case, description of other public projects which face the same issue, (your) library/framework to solve the problem statement, proposals for improvement and — often forgotten — public source code.
For one bad example: the latest hype in C++ conferences was functional programming (immutable data structures, monad-like chaining, etc.), and I saw talks centered around the guys' home projects which were advertised to the fullest on their blog with code excerpts, but none of it was ever published. Then on the other hand, functional programming libraries like brigand became popular also because they were made public immediately with a request for trying it out, including some good examples.

Real examples: This directly continues on the problems of hobby projects, but applies to all presentations. Without actual examples that people can apply to their own work or personal projects, a talk may not be informative (depends on topic, of course). For myself, I dislike variables named foo/a/b/whatever in examples. Many speakers present a problem that came from a real work problem. In my previous blog posts, I used examples from the financial sector in which I work, for instance. Try to put your real problem statement into a minimal (source code) example, removing all the confidential, over-detailed and useless stuff. You will even find out that if you do so, you may be able to reuse that problem statement as job interview question for software developers!
And please, for the love of all we honor as modern software developers, stop using Monkey, Giraffe and Animal as class names. Not even a zoo’s source code would have such a thing! The only exceptions may be study classes on object orientation and I even admit to have used those names myself on a covariance question when I was younger, but please, keep those and other nonsense examples out of technical talks. Show real use cases.

Number and size of slides: It feels sad that people still do this wrong even though it’s common sense and by just practicing your talk once (even mumbling it to yourself in silence), you can find out that you have too many. I never saw the case of too few slides — never! But I saw the opposite — a guy presenting way more than a hundred slides in a 60 minutes slot, constantly skipping content that he said was not relevant for the audience. Remember that the slides exist to guide the audience, not you, and your voice and highlighting is there to amend and explain the slides. There’s no silver bullet for the ratio of slides per minute, but quite clearly if you find you have to present 2 slides per minute with lots of content or code examples, that simply is not comprehensible at such high speed and your listeners will hate you. In school and university, I learned to put an agenda at the beginning. Even if that is not always very helpful for listeners, it is one way to provide a common thread to guide through your topic in a reasonable order.
There are many ways to reduce complexity by removing and shrinking content, and thus improve understandability:

Take care of details: Similar to typos in your examples which make them not compile, other small mistakes such as text typos, half-truths and incomplete explanations may lead to annoyances among the attentive people of your audience. You should be confident that your presentation is good and exact instead of creating it in a hurry.

Accent in English speaking: German speakers are a lucky few, because even if they have the typical, horrible accent when speaking English, it’s one of those which everyone can still understand. However the Germans also have something called "Denglisch", a bad mixture of German and English words, which can lead to misunderstanding. For instance, the German word "Handy" means "mobile phone", and if you mix that into an English sentence, people will be justifiably confused since in English, "handy" means "practical" or "useful". You should be aware of your own accent and such language traps and avoid them. Clearly, speaking perfect English is harder for people of certain cultures, but everyone should try their best when talking to an international audience.
The typical stereotypes and prejudices about how certain peoples speak English very often hold true, especially if speakers are unaware of how they speak English, so you may be able to just find out something about your culture/language/people by researching (insulting) comments about it. Seriously! To give you a personal example: I googled "german speakers accent horrible" and found e.g. Why are Germans among the worst speakers of English?, which felt somehow insulting, but since as an adult I don’t care much, I read on and found quite good reasoning by the author and others.
The difference of languages and cultures is a big source of trouble in listening comprehension and a topic of its own. I might give more hints on that in a future article, but here it is too much.
Summary: be aware of how you speak! If you know of your accent, and hear that you cannot avoid it completely, at least try to speak slowly.

Do not turn around to your slides on the wall: you should have a mirrored display (or presentation mode) on your laptop or second screen. You are turning around because you are feeling unsafe — similar to putting a hand in your pocket. Knowing your content or at least the order of chapters helps not needing to look up the slide content all the time. Presentation or mirror mode can show you the current and/or next slide if you need to see it.

Practice: Many people don’t like rehearsing their presentation in front of a mirror, with family, colleagues or friends or even by themselves. That’s natural and often even unnecessary. Regarding stress level: you are not in a job interview (if you are by any chance, ignore this hint), no need to haste or feel unsafe. Think less and keep the presentation style simple and your voice calm but controlled. The slower and more calm you are, the lower the risk for increased stress levels are. Watch a few minutes of Louis Dionne’s Meeting C++ 2016 keynote to see the meaning of that hint. He is the best example — exaggeratedly calm in some people’s opinion, but yet doing a perfect presentation with close to zero glitches or mistakes 👍.
To get a real preparation for a bigger event, you can try a local meetup group, present at your company or in another small setting. You could extract a small part of your slides into a lightning talk to check if people like the topic at all. Request and collect feedback from the rehearsal/practice session audience.

Speak loud and clear: Some rooms simply have bad acoustics and you can make up for it with your voice. It also makes listeners think that you are feeling confident about your topic. But do not speak too fast — as mentioned above, try to keep your pace and style calm.

Know your own quirks: You should be aware of your own behavior and speaking. Practice and feedback can help find out what you didn’t know yourself yet or didn’t want to realize. Example: many people say the same words or phrases all the time. It’s a pity that humanity is so fearful that we do not tell each other, but no way to change that at large. I know there are people who have that as invalidity or uncurable illness, but for the ones who can control themselves — just listen to yourself to find such tics. It even happens to keynote speakers ("you know"). Other popular words to accidentally repeat are "I", "so", "amazing" (or similar), "like" and of course "ummmm".

Do not read full slides aloud, separate "inputs" for listeners: Your audience can mostly only concentrate on one input at a time — voice, code, slides, seatmates whispering, other distractions. This is the very reason why your slides' content should be complementary to your voice, and therefore avoid too much text on a slide. Summarize in very short sentences if the slide has bullet points, or use emphasized text. If it’s about code, amend the code on the slide with your spoken explanations. From an "input" point of view, listeners should switch between 1) having the time to look at and understand your code and 2) you explaining it. Obviously not all brains are of the same effective speed and not all listeners an expert in your topic, so there must be appropriate "thinking breaks" in between (remember to talk calmly!). Provide good, slow example descriptions, and mind beginners and people who are not deep inside the topic.
At the conclusion slide, it’s fine to list things that were already mentioned in short, to repeat them verbally and/or in writing.

Use latest tools: In one particular presentation of Meeting C++ 2016, I saw a C++11 implementation of what was already available in C++17 as built-in feature. While all other speakers were already showing off trunk compiler features which would soon be shipped as implementation of the new 2017 standard, I had to read slides which proved not only that it can already be done now, but also that I have to use ridiculous templating tricks and go through 50 copy-pasted lines of code on one slide just to get a point across that did not help the actual example, but which would also become obsolete in only a few months.
If you don’t want to make the effort of building/installing the latest compiler, just use online tools like compiler explorer (but mind that you may be offline during the presentation).

Consistent examples: Try to keep your examples centered around one topic. Be it one use case, one other programming language to compare to, and so on. Try to keep the variation low to guide watchers, not confuse them. One real-life example I experienced was a talk loosely related to functional programming which pointed out some wildly mixed examples in both Python and Haskell, a combination which was obviously quite unfamiliar to most of the (C++) audience, especially given Haskell’s syntax which is not immediately comprehensible.

Working examples: Make sure your examples actually compile. A great way to do so is to add a Makefile to your slides repo, and embed the source files into your slides, instead of copy-pasting examples into slides directly. Provide a precompiled header to remove all the clutter (e.g. for C++: includes, using namespace statements, repeated example types), so that only the relevant part is imported from the source file into the slide. Having your examples compile allows you to demo and adapt your use cases if someone has a question.

Display your keystrokes (topic-dependent): If you are showing an IDE or anything else where shortcuts, pressed keys and clicks help the understanding, use a tool to display what you are typing.

Do not disturb: Nothing is more annoying than notifications and applications popping up while you present. You have to say "sorry" and probably it is even something embarrassing like a chat or e-mail notification including content. Take measures to avoid such a situation:

Internet access: Hopefully, you’re fully prepared without requiring any online resources. Wi-Fi access is often a pain or sometimes even unavailable, so try to open websites beforehand or store resources on disk. The same applies to software and packages that you need to have installed. If a Wi-Fi is available, connect early enough and consider a temporary WLAN hotspot of your phone’s mobile connection as backup.

Display/projector problems: Conference organizers can bring tons of cables and adapters, but still we can see problems in 2 out of 10 presentations. Before one particular talk, I observed 6 software engineers and 2 venue assistants trying to get to one out of two laptops to work with the projector — for over 10 minutes. Organizers should offer the speakers to try that out before, and if so, take that chance.

Try a presenter mouse if you are the type of person to walk around, or the room setup forces you to stand far from your laptop ("Can I have the next slide, please?"). The model should be easy to handle with a fixed grip and have all the features you need, e.g. next/previous slide, start presentation, laser pointer and probably extended features like media controls, right click, touchpad for cursor moves and whatnot. A regular mouse can serve as stupid backup if things do not work on the spot. Try out the presenter mouse before the presentation to get to know how to use it (and potentially install required drivers while you are still online). I’m using an older version of this Logitech model which serves me well with the most basic features.

Laser pointers may not show up on mirrored canvases — for instance, talks with large audiences are sometimes in a venue that has one main projector on stage, and more projectors for people in the back). The small dot could also be invisible in the video recording. Alternatively, select text with your cursor, which is easy for PDF and HTML-based slides. Other tools like PowerPoint include markup tools to highlight text. Or use the old-school "one bullet point at a time" feature to reveal only the passage or code snippet you are currently talking about, to allow people to focus on the right spot of your slide.