In this section of Language in Thought and Action, semanticist S. I. Hayakawa illustrates a concept that, in my experience, is a crucial part of clear writing:1
Try the following experiment on an unsuspecting friend:
“What is meant by the word red?”
“It’s a color.”
“What’s a color?”
“Why, it’s a quality things have.”
“What’s a quality?”
“Say, what are you trying to do, anyway?”You have pushed him into the clouds. If, on the other hand, we habitually go down the abstraction ladder to lower levels of abstraction when we are asked the meaning of a word, we are less likely to get lost in verbal mazes; we will tend to “have our feet on the ground” and know what we are talking about. This habit displays itself in an answer such as this:
“What is meant by the word red?”
“Well, the next time you see some cars stopped at an intersection, look at the traffic light facing them. Also, you might go to the fire department and see how their trucks are painted.”
The principle? When explaining things, be concrete rather than abstract. Specifically, go from the idea itself, which your reader does not understand, towards more concrete explanations of that idea, rather than explaining the idea solely in abstract terms.
The simplest way to do this is to give examples. Often, more understanding can be communicated in a few real-world examples of an idea than in a thousand words of abstract explanation.
For example (👈👈):
- In “Unlaunching”, I explained my personal experience with building a web app and writing and the conflict between those two endeavors. Imagine if I had instead discussed agentic quitting entirely theoretically—it would be painfully dry, and probably harder for people to relate to.2
- This article comparing the humor skills of LLMs and Markov chains starts with an example but then discusses the comparison in the abstract. This would be fine if it came back around and offered additional examples, but, as it is, it ends unsatisfyingly.
- This segment of Ryan Singer’s explanation of Christopher Alexander’s design philosophy starts abstract (and, as a result, hard to understand—form? context? huh?) but drops into two specific examples (the apartment building and the planter box) that will make you think differently about everything manmade.
One or two examples can sometimes suffice (Hayakawa gives two in his concrete definition of red above), but I use three as a rule of thumb. Naming three examples of an idea is typically not too difficult, but it enhances clarity beyond what one or two examples provide.
Including three examples also gives you room to illustrate different facets of the same idea. I did this with my Innerhelm post on persistence, in which I shared Clifford Ashley’s work of writing The Ashley Book of Knots, a friend’s battle with alcoholism, and my own writing efforts as examples to illustrate the value of persistence, the pitfalls of consistency, and how persistence and consistency together lead to meaningful achievement.
This principle even impacts my work as a software engineer. Providing specific examples is a big part of what makes good code documentation, but it’s not uncommon to encounter documentation that offers no examples and is therefore much harder to wrap my head around as someone with no prior exposure to the ideas.3
Want to write better documentation, blog posts, or anything else? Next time you need to explain an idea, give three examples. It’ll make your writing clearer and more impactful.
Footnotes
-
I came across this excerpt via an article by Eliezer Yudkowsky. ↩
-
To this end, I included “Story-based, not purely theoretical” as one of Innerhelm’s brand values. Not all of my posts have been great at this, but it’s something I strive for. ↩
-
The documentation paradigm Diátaxis includes Tutorial as one of the key components of good code documentation for this reason—it enables quickly constructing an actionable mental model in ways that reference documentation, for example, does not. ↩
Comments
0 comments
0 replies