Many conference speakers struggle with how to introduce their topics. For example, if your talk is an introduction to higher order functions, you might find it turning into a list of facts, beginning with a definition of the topic:

• Higher order functions are functions that take other functions as arguments.
• Here's one higher order function, map(f, xs). It calls f on each x in the list xs.
• Here's another one, reduce.
• Etc., etc.

This isn't very engaging for the audience because they don't know why these things are interesting, or useful, or even why they exist at all.

It's much better to start by presenting a problem, without mentioning its solution. Show why the problem is actually a problem. Then, when you present the solution, the audience understands why it's important. For map, you might say something like this:

1. Traditional imperative for loops require you to keep track of the index variable yourself.
2. Here's a bug that you can easily introduce when traversing a list in reverse with a for loop: for(i=items.length; i>=0; i--). The index management is wrong; it should begin for(i=items.length-1; ...). There is no item at index items.length!
3. Here's the map version, which eliminates the index variable and more directly says what we mean, so we can't even make that indexing mistake: items.reverse.map { ... }.
4. Map is a higher-order function – a function that takes a function. HoFs can hide details that we'd normally have to manage manually.

Now that the audience has seen one example of HoFs being useful, they're motivated to learn about HoFs more generally. You've told a little problem-solution story, even if the whole story only took one minute.

This works for more than just code. Maybe your talk is about managing code repositories. You can tell a short story about two highly diverged branches where merging was almost impossible. Ideally, show a merge summary with hundreds of merge conflicts. Now you can describe the practice of doing trunk-only development with feature flags, where there's no merging required, so there are no conflicts. The audience will understand that it solves the nasty problem you just showed – a problem that they've probably had.

Real-world examples beat synthetic examples. "Git merges can have arbitrarily many parent branches" is just a fact about git. But "the Linux kernel's git repository contains a single merge with 66 parents" is a much more interesting fact!

Stories about examples beat mere examples. A story adds context: What happened to cause this? What happened as a result? "The Linux kernel's git repository contains a single merge with 66 parents" is an interesting fact about the world. But you immediately want to know: what were the kernel developers doing that caused that? It turns out that the merge itself was relatively mundane, but it prompted "that's not an octopus, that's a Cthulhu merge" from Linus. A Cthulhu merge always beats "git commits can have many parents"!

Adding motivating details may make each topic take up more of your talk time. That's OK; a conference is not a competition for who can mention more ideas in one talk.

Sometimes, you can still mention a removed topic. To return to our example of the map function: maybe you show map, preceded by a motivating example. Then you mention that reduce is another higher-order function that people might've heard of. Most people will forget about reduce instantly, but the ones who have wondered what it is will be interested. You spent only a couple seconds to generate that interest, which is probably a good trade-off. Explaining the details of six different higher-order functions probably isn't a good trade-off, because most people will forget most of the detail.

Your talk can't be made entirely of motivating examples, but they can help with structuring. Show a motivating example before introducing a solution; that way the audience will know why they should care about the solution. Make the examples realistic if you can do that briefly; otherwise, don't feel bad about using a synthetic example.

This grew out of advice that I wrote for some speakers at Deconstruct. Registration is open!

This post was also motivated by Locked doors, headaches, and intellectual need, an excellent post on a more general version of this idea.

You might also like our other posts about preparing talks.