paulmck

This is part of the Kernel Recipes 2025 blog series.

A well-crafted story covering a boring topic can be far more entertaining than a haphazard story covering an exciting topic. As they say, it is all in how you tell the story.

That bridge that an earlier section told you to build? You would be wise to build much if not all of it out of stories.

There are many books, courses, and videos on story-telling, which you should take full advantage of. For example, James Patterson has a video series that I watched and learned from on a long airline flight.

The key point is to make your story interesting to your audience. In a technical talk, you have an advantage in that the audience most likely expects that they will need the information that you are presenting. Back in the day, stories of this sort were termed “war stories” in which novice soldiers would listen carefully to stories from veterans, with the expectation that those stories’ lessons would increase the novices’ survival rate. We can all be thankful that most technical talks play for much lower stakes, but the “war story” pattern still encourages careful listening.

Other story patterns include overcoming obstacles, finding treasure, glorious failure, and many more. Describing them and others is beyond the scope of this document, but it turns out that there is much literature on this topic. In the meantime, here are some example talks of mine for each category:

1. War story: “What Happens When 4096 Cores All Do synchronize_rcu_expedited()?”
2. Overcoming obstacles: “RCU's First-Ever CVE, and How I Lived to Tell the Tale”
3. Finding treasure: “Bare-Metal Multicore Performance in a General-Purpose Operating System (Adventures in Ubiquity)” where an attempt to spread wakeups across multiple tasks ended up reducing the number of wakeups by a factor of two. That said, LWN coverage termed this a war story.
4. Glorious failure: “Cautionary Tales on Implementing the Software That People Want”, especially the “Eight-Bit CRM” section starting on slide 18 in which my highly acclaimed and innovative early 1980s software system was defeated in the market. By a filing cabinet.

Of course, better examples of these story patterns and many more may be found in the works of professional speakers and writers. Unlike these professionals, I tend to add the story pattern later in my preparations. This is because my first priority is not to tell a story, but rather to communicate some technical information. For me, the story is therefore simply a means by which to communicate technical information, not an end unto itself.