paulmck

This is part of the Kernel Recipes 2025 blog series.

You own your words until the moment they leave your lips.  At that moment, ownership passes to your audience members, each of whom is free to interpret your words as they will.  In particular, they are free to misinterpret your words.  And trust me, they will do so.

If you give a presentation that is misinterpreted, it is tempting to blame the audience.  But this is the wrong reaction.  That misinterpretation is instead a bug report against your presentation.  Fix that bug as you prepare for the next instance of that presentation.

This applies doubly for documentation.

But what of audience members who intentionally misinterpret your wording?  This might still be a bug report.  Or it might be parody, and thus an opportunity to laugh at yourself.  And if laughter is good medicine, laughing at yourself is the best medicine, despite how it might feel at the time.  In fact, you might find it helpful to include that parody in the next instance of that presentation in order to spice things up a bit.

Does this mean that you must prepare each and every talk so as to be comprehensible and entertaining to anybody and everybody?

Not necessarily.

After all, university courses often have prerequisites, so that advanced classes can focus on new material rather than having to recap all of the prerequisites. And this can also be the case for presentations.

For example, during my time at Sequent in the 1990s, I was the guy who explained how to take kernel crash dumps. Initially, my target audience was kernel developers and technical service people, and so I targeted them, relying on their knowledge, skills, and abilities.

This worked well, but only for a few years, after which it became necessary for technical sales people and less-technical service people to take crash dumps. At that point, I needed to adjust in order to suit their knowledge, skills, and abilities. I did this by watching while technical sales people attempted to take crash dumps and adding material as needed until they were successful.

So you can restrict your audience, just as many university courses restrict theirs. And you will likely always need to. Returning to a previous example, it is probably not going to be all that useful for me to make a presentation on Linux-kernel RCU internals accessible to quantum physicists, any more than it would be for them to make their presentations accessible to me.

In short, understanding your audience will help you create a presentation that is more likely to have the desired effect. Your audience might well change over time, and if so, your presentation will also need to change.