This post is part of my ongoing scientific style guideline series.
Imagine you’re writing a science paper. The journal you’re going to submit it to specifies a word limit: 5,000 max. You open the stats in your finished draft — 5,523 words. You’re going to have to cut.
Problem is: everything you wrote is important! You can’t take out anything from the Methods or Results sections: that would make the study weaker and less likely to be accepted for publication. You can’t take out any of the background information in the introduction: you already included the bare minimum for readers to understand the rest.
Although, on closer inspection, perhaps not quite the bare minimum. You reread this sentence:
Most models of trait evolution are based on Brownian motion, which assumes that a trait (say, beak size in some group of bird species) changes randomly, with some species evolving a larger beak, some a smaller one, etc.
What if you removed the parts that talk about beak size? That’s not strictly necessary.
Most models of trait evolution are based on Brownian motion, which assumes that a trait changes randomly.
There we go. More concise, more to the point, and most importantly, you shaved off 23 words from that word count. Of course, the sentence is less illustrative, but whatever: your readers are smart, they’ll be able to figure out an example on their own. Right?
Wrong.
Well, okay, not quite wrong, your readers probably are smart. But this goes against the Minimum Reading Friction principle. The point of most writing, including science papers, is to do the work so that readers don’t need to. If readers need to think of an illustrative example themselves to fully understand your abstract idea, then you’re asking a big effort of them.
Picking good, concrete, relevant examples is a lot of work, whether as a reader or writer.1Here’s an aside that’s not directly related to science but, instead, to computer programming.
When coding, you’ll usually refer a lot to developer documentation about whatever preexisting code you’re using. E.g. you want to convert a date to a different format, so you look up the docs for the function
convertFormat(someDate) -> convertedDate. The docs will describe how the function works, what its input (someDate) and outputs (convertedDate) exactly are, and so on — but very often they will not include an example of using convertFormat() in code. If there is an example, it’s often trivial and not very helpful. When I worked as a programmer, I was commonly frustrated by the lack of examples, both because I wanted to figure out quickly how to use a complicated function, and because I wanted to know about any usage conventions.
I suspect that writing documentation would be a lot more work if it included clear and relevant examples everywhere, which is probably why it’s rarely done. I realize this constantly when I write. It’s very tempting to just state an abstract idea and not bother finding a good example to illustrate it. After all, the abstract idea is more general and therefore more valuable — provided that your readers understand it.
I struggled with example-finding in this very essay. It took me a while to think of the opening about cutting examples to respect a word count limit. And I’m not even that happy with this example. For one thing, it’s not very concrete. For another, it’s not even the most common reason for lack of examples: usually, we don’t cut them out, we simply fail to come up with them in the first place.
And so, unfortunately, this piece of guidance is less of a Low-Hanging Fruit than others: adding good examples is a skill that takes some practice. At the very least, it’s not difficult from the point of view of structure, since it doesn’t require you to rethink your argument — you usually just need to add a sentence or two.
Here are a few other minor points:
Where should examples be placed relative to the main idea?
It’s most intuitive to place an example right after the idea it supports, and that’s probably fine most of the time. But there are benefits to placing an example first.
Consider:
Left-handedness seems to be somewhat correlated with extraordinary success, including political success. For example, despite a base rate of about 10% left-handedness in the general population, four of the seven last United States presidents — Barack Obama, Bill Clinton, George H.W. Bush, and Ronald Reagan — were left-handed.
vs.
What do US presidents Barack Obama, Bill Clinton, George H.W. Bush, and Ronald Reagan have in common? They were all left-handed. In other words, four of the last seven presidents were left-handed, compared to a base rate in the general population of about 10%. This suggests that left-handedness is correlated with extraordinary success, at least in politics.
I find the second version more engaging. You see an interesting fact, you’re drawn in, and then the writer tells you the more general point when you’re most receptive.
Journalists do this a lot. They opens with a story, and then proceed to make their point.
What types of scientific writing does this apply to?
Anything that deals mostly with abstract ideas. Highly concrete writing, such as the sections describing the methods or results of a study, aren’t concerned. Thus, in a typical experiment paper, this advice is mostly relevant to the discussion section and some of the introductory background.
Authors of literature reviews may need to be more careful. These papers integrate a lot of ideas from reviewed studies; it can be tempting to skip examples in order to include more content in less space. The paragraph I worked on here was from a literature review.
What about word limits, though?
Sometimes you really are constrained by externally imposed word limits, and sometimes the examples really are the the least problematic thing to take out. In those cases, well, do what you have to do.
In JAWWS, I don’t want to be strict about word limits. They often force writers to sacrifice clarity to satisfy other components of the four-way tradeoff. They’re also not as relevant in an age where papers are rarely printed on, well, paper. On the other hand, I imagine that many other publications first think that and then have to implement limits to avoid very long submissions. I wonder if the solution could be to make concrete examples not count, provided it’s not too difficult to identify them.
Recommendations
- Support each abstract idea with at least one example
- Complicated abstract idea may benefit from multiple examples
- Choose concrete, specific examples that can be grasped immediately
- When possible, put the example before stating the underlying idea
See also
- Slate Star Codex’s Nonfiction Writing Advice, section 6 “Use concrete examples”