Context: I keep promising that I’m going to write a blog post about explaining things and I’ve tried three times, but it keeps getting unwieldy, so this is an attempt at a short blog post about how to explain things.
Intended Audience: Everybody.
Epistemic Status: I am pretty confident that this is true, but it’s necessarily an oversimplification.
There are exactly three things you need to do in order to explain things well:
- Decide what you want to explain.
- Find out what the listener already knows.
- Express the first in terms of the second.
People routinely miss anywhere between one and all three of these steps, which is unfortunate because every one of these steps is vital if you want your explanation to do anything useful.
I will now briefly elaborate on each step.
Decide What You Want to Explain
This may seem easy but it’s not. This section is the important bit.
The key thing that people miss is that you are not trying to explain everything that is possibly relevant, you are trying to find the subset that is useful to someone.
Take my research. I’m a PhD student, so people often ask me what my research is about. They usually do this with a note of trepidation in their voice hinting “I’m too stupid to understand this, but…”. That is because they expect that as a PhD student I am bad at explaining things to normal people.
The following is what I say:
I work on a problem called test-case reduction. That is, you’ve got some program with a bug, and you’ve got something triggering a bug. Say a big document crashes word or something. Debugging these problems is annoying when the thing triggering the bug is large and complicated, so to understand the bug we want to try to trigger it with something small and simple. Doing that by hand is tedious, so I work on tools for automating the process of turning that initial large, complicated, example into something smaller and simpler that is easier for a person to debug.
I could talk about why this is hard, or algorithmic complexity issues, or shortlex optimisation, and if I did that then the person would nod and smile and go find someone else to talk to because none of that is relevant to them.
A good rule of thumb here is that you should always explain the problem, not the solution, unless the person you are talking to already understands the problem. This is also the approach I took with my neural networks post – it makes no attempt to really explain what a neural network is, only the problems they solve.
Find Out What the Listener Already Knows
Ask them. I usually start my explanations of my research with the question “How familiar are you with software testing?” followed by “Have you heard of QuickCheck or Hypothesis?” if they say they are fairly familiar.
If you can’t ask them because it’s an article, decide what your target audience is and assume they’re on the lower end of understanding for that audience. Ideally find some beta readers who are in that target audience.
Edit to add: David Jones pointed out on Twitter something you can do when writing that helps here, and that I don’t do enough, which is to be explicit about who the article is for so that your audience can self-select in or out. My “Attention Conservation Notice” and the new “Intended Audience” classifiers help a bit here, but it can be useful to have a longer paragraph saying “This is what you’ll need to already know to get much out of this post. Here’s a link to some background if you don’t know that.”
Express the First in terms of the Second
In order to explain things to someone you must do so in terms of concepts they already have. This may require you to give them concepts that they do not already have before explaining the thing you actually want to explain. The term I use for this is “the abstraction stack” – you have a stack of abstract concepts each building on top of the ones below it.
For example, in my “what is a neural network” post, I had to explain what machine learning was before I could explain what a neural network was. Indeed, most of the post was about explaining what machine learning was. Similarly, when explaining Hypothesis, I usually spend more time explaining software testing to lay people than I do explaining Hypothesis or property-based testing.
Broadly, the goal of explanation is to help someone build up their abstraction stack until it contains the thing you want to explain.
The following two techniques are the most useful things I can tell you about how to do that:
- Make sure they understand the current level before putting something on top of it. Generally this means you need to explain the foundational things more than the one you are explaining.
- Every time you introduce a new concept, illustrate it with examples of the concept.
How do people get this wrong?
The main thing that causes people to get this wrong is what’s called “curse of knowledge” – you tend to discount things you already understand as much easier than they actually are. This causes people to skip over details.
For example, suppose someone at a party asked me what Hypothesis was. I could say something like:
It does a thing called property-based testing, which lets you parametrize a software test by a source of input data. This comes from a tool called QuickCheck, whose goal was to bridge some of the gap between software testing and formal verification.
This is a perfectly reasonable explanation that will almost certainly fail to land, because I have assumed people understand all sorts of things that they almost certainly don’t.
Another way this can fail is to rush over bits that are obvious to you. For example I could have explained neural networks as follows:
Machine learning is a way of making automated decisions. Neural networks use multiple layers of “neurons” to try to make these decisions better. The stacks of layers let you build up complex features that understand structural information about the data that flatter machine learning techniques will fail to pick up on.
This is true and if the listener already understands machine learning is probably fine, but because of the amount of elided context they will probably get a really bad idea about what is possible and assume machine learning is much more powerful than it actually is.
How can you start getting it right?
The following three rules will put you on the right path:
- Begin by explicitly deciding what you want people to get out of your explanation. Try to keep this as small as possible.
- Begin all explanations either by asking what they already understand or by considering a model recipient of the explanation.
- Think explicitly in terms of the abstraction stack between your end goal and where the recipient is now.
These won’t result in perfect explanations, but if you are not already doing these things then fixing that will almost certainly result in improved explanations.
Despite the title there are a bunch of limitations to this method – not cases where it doesn’t apply, but cases where it on its own is insufficient.
Danil Suits points out on Twitter that there’s nothing in the above for helping people unlearn prior flawed understanding. That’s true. I don’t currently have any good advice for that. I think all of the above still helps in that scenario, but you need an entire separate set of skills and techniques for debugging failure to understand, and you may also need to be good at persuading people for the cases where they refuse to understand or actively disagree.
Another thing I’ve since realised is that this method assumes that they are able to understand the thing you are explaining – someone with cognitive difficulties might struggle with that, or require reframing of some of the abstractions that you used to understand the problem.
It also assumes that the recipient is motivated to understand. I struggle with this when teaching – I can generally do a good job of framing things in terms of reasons why someone should care about them, but at some point you hit a wall when someone is fundamentally uninterested in learning, and I don’t know what to do about that (part of why I’m not a teacher I guess).