When you teach someone a concept, you’re building a structure in their mind by connecting up some of their mental concepts in a certain way. But you have to go in through their ears. It’s kind of like building this ship-in-a-bottle LEGO set.
In this post, we’ll visualize what’s happening in a learner’s brain and see how a teacher can wield their specificity powers to teach concepts better.
Mind-Hanging A Concept
Reading a startup’s pitch begins as a learning exercise: learning what the startup does. In How to Apply to Y Combinator, Paul Graham writes:
We have to read about 100 [applications] a day. That means a YC partner who reads your application will on average have already read 50 that day and have 50 more to go. Yours has to stand out. So you have to be exceptionally clear and concise. Whatever you have to say, give it to us right in the first sentence, in the simplest possible terms. […]
The first question I look at is, “What is your company going to make?” This isn’t the question I care most about, but I look at it first because I need something to hang the application on in my mind.
It’s worth unpacking and visualizing this part of PG’s advice, because we’ll see that the power to mind-hang the concept you’re trying to communicate is closely related to the power of specificity. Stay tuned for that.
First, one more snippet from PG:
The best answers are the most matter of fact. It’s a mistake to use marketing-speak to make your idea sound more exciting. We’re immune to marketing-speak; to us it’s just noise. So don’t begin your answer with something like “We are going to transform the relationship between individuals and information.” That sounds impressive, but it conveys nothing. It could be a description of any technology company. Are you going to build a search engine? Database software? A router? I have no idea. […]
One good trick for describing a project concisely is to explain it as a variant of something the audience already knows. It’s like Wikipedia, but within an organization. It’s like an answering service, but for email.
I recently helped the founder of PierShare craft his YC application. For the “What is your company going to make?” question, he had originally written the first sentence:
PierShare is a new way for boat owners to easily rent a dock.
This is actually a pretty good answer because it’s matter-of-fact, not marketing-speak, and I can already guess at a plausible Value Prop Story [LW · GW]. Still, I recommended taking PG’s advice to describe his company more concisely as a variant of something the audience already knows:
Liron: Why not just write that you’re “Airbnb for boat docks”?
Founder: Hm, how is that better though?
Liron: It builds the reader’s mental model better and faster. Notice how in the next part of your application, you currently spend a lot of words describing these predictable qualities of your business:
* You have a user-friendly online system for both parties * You handle the payment processing * You handle the insurance stuff
If you just say “Airbnb for boat docks”, they instantly load a mental model of all that stuff, so you don’t have to spell it out for them.
Founder: But it has important differences! Like, Airbnb’s typical user just makes a one-time payment to rent someone’s home for a night or two, while our typical user pays an ongoing monthly subscription to stay at someone’s dock.
Liron: I agree that this difference is important enough to mention in your application, but still, the fastest way to build their mental model of your business is to start with their pre-built mental model of Airbnb and then apply a patch. This is true to such a degree that if you don’t invoke Airbnb as a shorthand to explain your business, they’ll be wondering why not.
Here’s what we came up with in the end:
PierShare is an Airbnb-like subscription service for boat docks.
This diagram of the reader’s mind illustrates how we’re mind-hanging the concept of PierShare:
Since we know the reader is a savvy investor, it’s safe to assume that the concept of “Airbnb” has an associated web of preexisting knowledge and intuitions. The reader knows that Airbnb is a marketplace broker, that marketplace brokers cater to two types of users: renters and rentees, that Airbnb has a streamlined customer experience, etc.
Compare this to “a new way for boat owners to easily rent a dock”:
Sure, we can expect some preexisting knowledge and intuitions about renting stuff in general, and boating/docks in general, but it doesn’t mind-hang the way “An Airbnb-like subscription service for boat docks” does. For example, the investor won’t be able to confidently predict that PierShare handles payment processing, without reading farther into the application.
Specifics Are Mind-Hangers
Here’s the complete answer we crafted for “What is your company going to make?” Can you tell what trick we’re using in the second and third sentences?
PierShare is an Airbnb-like service to match owners of water-docked boats (4M individuals in the US) to private dock owners (500,000 individuals in the US).
For boat owners who typically pay $1,000–1,800/month to dock their boat (that’s $12–22k/yr, and they need this for their boat’s 10- to 15-year lifetime), we let them find a privately-owned dock and save 30% ($4k/yr).
For dock owners (people who live adjacent to a waterway) who typically leave their docks empty because it’s too much friction and hassle to rent it, we give them an easy $1k+/month revenue stream.
That’s right, we’re hitting them with two Value Prop Stories! (Notice that a two-sided marketplace business always needs two Value Prop Stories: in this case, one for boat owners and one for dock owners.)
One reason for using Value Prop Stories here is that we want to show off the strength of the value-delta for both sides of the marketplace: putting an extra $4k/year into the pocket of each boat renter and $1k/month into the pocket of each dock owner.
But the other reason we’re using Value Prop Stories is simply because they add specificity to the description of what the startup does:
Dock owners are people who live adjacent to a waterway
Boat owners pay a lot for docking
Every year, there’s a lot of money at stake for both
We’re using Value Prop Stories to slide “Airbnb for for boat docks” down the ladder of abstraction.
And in general, any time you’re trying to explain a concept to someone — in this case, the concept of PierShare — it’s helpful to slide it down the ladder of abstraction because specific details function as mind-hangers.
Teach With Examples First
When you want to teach someone an abstract concept, keep in mind that people love climbing the ladder of abstraction [LW · GW] from bottom to top. Brains are good at generalizing from specific experiences, but bad at grasping general concepts directly from generally-worded statements.
Here, let’s ask your brain to grasp the following generally-worded statement of an abstract concept:
Don’t Fall for the Sunk Cost Fallacy: General Statement When deciding whether to stick to a plan or change course, your current plan’s sunk costs shouldn’t affect your decision, as long as you compare the total expected value of each option.
Did you manage to load the general principle into your head? Unless you immediately recognized this as a familiar principle, you probably had to read the description multiple times, slowly.
As your author, I should try not to make your brain do this! It’s bad explanatory writing to hit you with a general principle without first giving you a mind-hanger for it. Look at this mess of dangling concepts I tried to fling at you:
While the concepts I tried to fling at you have some internal structure to hold them together, they’re currently just dangling over your brain’s huge web of preexisting knowledge and intuitions. Frustrating, right?
But you probably won’t even think to blame me for putting you in this situation. You’ll probably blame yourself for being too “dumb” to deal with the dangling concepts that the “smart” author is trying to teach you.
Why did I put you in this compromised position? I guess I expected that you’d just keep my general statement dangling in your precious working memory, and keep reading onward to the next thing I’m going to say.
But now that we have the language of mind-hanging and dangling, we can see that this is an authorially-rude thing for me to do:
Hey chump, just keep reading my explanation while your brain thrashes on my dangling concepts. I have no problem hanging this in my mind, so what do I care? I’ll give you some mind-hangers whenever I feel like it.
Alright, let’s see the kind of mind-hanger I should have given you.
Don’t Fall for the Sunk Cost Fallacy: Specific Example Imagine you’ve paid $50 for tickets to see your favorite band perform a concert, but on the day of the concert, an unexpected blizzard hits your town. Now you have to decide whether to make the stressful one-hour drive through the blizzard to see the concert.
First, let’s assign dollar values to all your options (approximating your utility function):
We’ll define $0 to be the baseline value of your average evening when you haven’t bought concert tickets.
Seeing the concert is worth +$80 to you. (In other words, you were happy to buy the ticket for $50, but you wouldn’t have bought it for more than $80.)
Driving through the blizzard is worth -$100 to you.
Now all you have to do is compare the expected value of your two options: You can drive to the concert for an expected value of (-$50 ticket) + (-$100 blizzard) + ($80 concert) = -$70, or do something else for an expected value of (-$50 ticket) + ($0 average evening) = -$50.
Since -$70 < -$50, you should forget about the concert. It’s not worth going because of the blizzard. But if you’re not trained in decision theory, your intuitive thought process might go like this:
“The concert is worth +$80,and I’ve paid $50 for the tickets, so if I don’t drive to the concert, I’m missing out on the value of the concert and the value of the tickets, which is $130 of value!”
Here we say that your intuition is committing the sunk cost fallacy, because the non-refundable ticket price ($50) is a sunk cost which has no bearing on how much value you’ll gain or lose via your current decision whether to drive to the concert.
Hopefully that example was pretty easy to follow. And now that you’ve loaded it into your mind, you can use it as a mind-hanger to understand the general statement I’m trying to teach you:
Don’t Fall for the Sunk Cost Fallacy: General Statement When deciding whether to stick to a plan or change course, your current plan’s sunk costs shouldn’t affect your decision, as long as you compare the total expected value of each option.
The general statement probably feels more understandable now that you’ve installed mind-hangers for it.
My goal here obviously wasn’t to teach you about the sunk cost fallacy, it was to show you what it feels like when an author forces you to read a general description of a concept instead of spoon-feeding you specific details that build on your preexisting knowledge and intuitions. It’s easier to load a generic concept into your head if you first install mind-hangers for it.
By the way, my specific story even helped me understand the general concept better, because I realized that the -$50 of buying the ticket appears in both Expected Value terms, so it cancels out of the expected-value comparison. So I was able to connect my abstract concept of “sunk costs” more directly to my abstract concept of expected value:
The mind-hanging power of specific examples helps you teach others better and teach yourself better. Good to know, right?
In 2007, I stumbled on a life-changing blog post: My favorite pedagogical principle: examples first! by the mathematician Tim Gowers. It has transformed how I’ve been communicating concepts ever since. It was also the first inkling I ever got about the power of specificity. (It was a few more years before the dam broke and the other powers came rushing into my purview.)
Here’s what Tim says is “a very simple idea that can dramatically improve the readability of just about anything”:
Present examples before you discuss general concepts.
So I’m not making an original point here; I’m repeating Gowers’s point, albeit with a bit less math. I’m also classifying “teach with examples first” as a kind of specificity-based mind-hanging power that deserves to be collected and showcased together with other specificity powers in a stupendous listicle.
The Tragedy of Human Working Memory
Why does our reading or listening comprehension break down when we’re presented with a general concept before a specific example?
When you were first reading my 32-word general statement about avoiding the sunk cost fallacy, it taxed your working memory more than usual, and probably overloaded it. On the other hand, when you were reading my example of driving through a blizzard to see the concert that you bought tickets for, it didn’t demand as much of your working memory, even though the total number of words was almost 10x higher. Why is that?
One of the saddest things about the human condition is how underpowered your working memory is. Your brain has 100B neurons and is the smartest thing in the known universe, but remembering a seven-digit phone number is a struggle — are you kidding me?
You can be a highly intelligent person, but if I fling a handful of dangling concepts at you and you’re not ready with a sturdy mind-hanger, you’ll just try to fasten them down with whatever you can: a few measly strips of working-memory duct tape.
It’s sad because the amount of working memory we have might be an easily-tweakable genetic parameter. Natural Selection might have been stingy with this parameter’s value because we had enough for our ancestors’ needs. But now we’re trying to build a technological society and it’s clearly not enough working memory for our needs.
A superintelligent mind with a reasonable amount of working memory could process generic statements all day long and never whine about dangling concepts. (I feel like the really smart people on LessWrong and Math Overflow also exhibit this behavior to some degree.) But as humans with tragically limited short-term memories, we need all the help we can get. We need our authors and teachers to give us mind-hangers.
Mind-Hanging vs. Grounding
We’ve defined [LW · GW] grounding a term as describing a specific stimulus that you’d mentally classify within that term. That kind of description falls within the shared space of both conversation participants’ preexisting knowledge and intuitions. So any grounding is also a valid mind-hanging.
On the other hand, you’re allowed to mind-hang a concept on any other concept that your conversation partner is familiar with, so it’s sometimes possible to offer people mind-hangings that aren’t also groundings. For example, if our conversation partner was extremely familiar with decision theory, our general statement about the sunk cost fallacy wouldn’t be dangling concept in their mind; the whole structure could hang entirely within their preexisting knowledge and intuitions.
Great post! Very clear, especially the Paul Graham/start-up pitch section.
Small feedback though "mind-hangers" continue to feels weird as terminology to me. Like I've managed to get my mind to attach to the concept you're pointing but it somehow still feels wrong, like each time you use it I need to run a patch to substitute in the actual thing.
Other than that, seems pretty spot on. I think there is a caveat to be made that even when leading with examples, you want to be clear upfront what the examples are going to be an example of, e.g. "I'm going to give you an example of Sunk Cost Fallacy." Not a mistake I think you're likely to make, but sometimes people start with particulars and you have no idea where they're going.
I guess generally the "start with examples" needs to be differentiated from different good advice (particularly for business contexts) which is "start with conclusions." The advice is actually compatible since conclusions can be very specific and conclusions often serve as very useful "mind-hangers." Once I know what you're arguing for, I can start to assemble each of the pieces you're giving me. So in short, start with examples doesn't necessarily mean start with nitty gritty details.
Thanks! I’m definitely open to calling it something other than “mind-hanger”. I called it that because I’ve never seen anyone call it anything except Paul Graham writing “something to hang the application on in my mind”.
Here’s what I think a mind-hanger (or other term X) refers to: before you can build a new structure in your mind that you can expect to remember and reason about, you need to start by thinking about mind-hangers/X’s that are already well-established in your web of preexisting knowledge and intuitions.
I think I also realized another specificity-angle to this (in addition to “specifics are good mind-hangers”):
When you endeavor to teach someone a concept, you want them to come away with that concept connected to their preexisting knowledge and intuitions. Ok, which specific preexisting knowledge and intuitions? Don’t rely on the person to hang your lessons in some unspecified way. Pick a specific mind-hanger and surgically install your lesson on it.
The etymology makes sense. Perhaps the issue is that mind-hanger makes it sound like it is the thing doing the hanging rather than the thing being hung upon. Perhaps "pre-existing mental hooks" is closer.
Even this still feels slightly off because the name feels like it implies those concepts exist for the purpose of being hooks rather than happening to be the most suitable concepts to build upon. So perhaps "hookable concepts" or something. "Hook points." Those don't sound great, but conceptually they feel like they fit better maybe.
When you go to teach someone something new, you should try to find suitable hookable points in their pre-existing knowledge. Or something.
Personally, I thought "mind-hanger" was ok. I got an image of a coat-hanger for the mind. You could even include that image explicitly in your concept mapping pictures.
Some other ideas that stick with the coat-hanger variant would be "idea-hanger", "concept-hanger".
Another term you might consider is scaffolding. This also has a strong concrete image of construction scaffolding, but the metaphor lends itself to the idea of building on top of the skeletal example, just as we start a building project with a scaffold and then build the real building around it. Often the scaffold is removed at the end, which can also happen with abstraction, where we can throw away the pedegogic examples once we've mastered the bigger idea. We don't really build anything on top of a coat hanger (nor a ship's anchor).
Noting that I think this is a good explanation of "mind-hanging" (though like Ruby I don't particularly like that name), such that I would link people to this in the future. Thanks! Also I double checked, and you seem to mostly teach this concept with examples first, good job :)
One variation of "give examples first" is "first briefly state the abstract principle, then the specific examples, then repeat the abstract principle", structuring the text so that the reader doesn't need to understand the first statement of the abstract principle.
I once saw someone on LW comment that for most people, "start with examples" works better, but for them, abstract-concrete works better than concrete-abstract. So as a result of that comment, I've often tried to go with the abstract-concrete-abstract pattern in my posts, figuring that that will benefit both kinds of readers. I'm not sure which approach is better in general, though for the startup pitch case it's obviously better to start from the concrete.
Yeah I know what you mean. I think in most cases, even for startup ideas, this might be a good template:
Extremely brief abstract statement - the YC application actually starts by asking “describe your startup in 50 characters or less” before asking “what is your startup going to make?” And I bet Paul Graham reads that first!
Concrete example as mind-anchor
As others have pointed out, #1 can be something of a “motivation-anchor” for caring about #2 because you want to know where the example is going before you start listening to it.
1+2 together are a mental-model “boot loader” for #3. And I think it’s important for #1 not to tax working memory so it can be free to focus mostly on #2.
I really enjoyed this post. It was fun to read and really drove home the point about starting with examples. I also thought it was helpful that it didn't just saying, "teach by example". I feel that simplistic idea is all too common and often leads to bad teaching where example after example is given with no clear definitions or high level explanations. However, this article emphasized how one needs to build on the example to connect it with abstract ideas. This creates a bridge between what we already understand and what we are learning.
As I was thinking about this to write this review, I was trying to think of examples where it makes more sense to explain the abstract thing first and then give examples. I had great difficulty coming up with any examples where abstract first makes sense. The few possible examples I could think of came from pure math, and even there I wonder if it wouldn't still help to start with examples.
The most abstract subject I've ever studied is category theory. Recently I was learning about adjoint functors, and here indeed the abstract definition make sense entirely independent of any examples. However, having learned the definition one can't really do anything with adjoint functors until one has seen it in some examples. So this might be an example where the abstraction-example-abstraction order or explanation makes sense. On the other hand, once I learned about the free-forgetfull adjunction, I thought that would have been a good example to start with to build intuition before introducing the abstract definition. I realized that my favorite teachers of the subject still use a lot of examples. Like Bartosz Milewski, who comes at category theory from the perspective of a programmer.
Learning to program is also a good example where in advance one might think it would make sense to learn a bunch of abstractions first. However, in practice, one learns to code by example, then after having mastered some examples, learning the principles behind them.
I think being specific and giving examples is one of the most valuable techniques I know for teaching things well. This post does a good job of conveying that insight clearly and intuitively (with many examples!), and helped me flesh out my model of why examples work so well, and how and where to use them
David Mamet has a great way to explain the urgency of being specific, "We can infer the general from the specific, but not the other way around."
I have also found it's useful to start with the most important thing you have to convey. When writing a first draft we tend to put it the last paragraph. But the clarity is almost always improved by making the last paragraph the first paragraph. Even if you are stating a seemingly ridiculous proposition, it seems best to get it out, then back it up.
If you don't put the most important part of the message first, there's a disconnect that can be utilized for comedic effect. But -- and I think that this is your point -- those disconnects are a huge obstacle to convey concepts. Now your reader or listener's brain wastes a lot of attention trying to figure out what's going on.
E.g. "You know those drapes you just bought? The blue ones. Yeah, they're on fire. And so's the rest of your house."
The post gives a lot of useful material even if I don't accept as-is a lot of it.
Trying to do specific concept building is very efficient if you are on point with your guess with details of the readers mental architechture. However if your guess is off the result can be actively harmful.
In particular I got seriously stuck with "blizzard is -$100". This is a pretty alien way to express things to me. And it seemed to be somewhat analogous to the concert grounding which seems that kind of thing might admit to rewording but the rewording didn't really succeed in my mind. Now I am tangled with problems with the auxillary tools and the point is obscured. Allthought it can be good in being spesific the possible issues are out in the open. If we stayed at more abstract level then my disagremeent on the details would not similarly interfere.
While it is good to be relevant and it is bad to leave the reader in a helpless state, I think there is a case not to subtitue the readers own participation. Mathematical style text where you are supposed to read very little very carefully can be completely approriate. It gets to the point. The long version while it didn't use that much memory took some time to read. A text that takes long to get gives you a better impression where the thing is going while text tha tis long one starts skimming or trying to guess where the text is heading.
I am reminded a lot about how in languages like C++ you CAN do your own memory management and it can be more efficent than standard automatic hanglng. But just because you CAN doesn't mean you SHOULD. Giving advice that you should always handle your own memory leads to cases where you spend a lot of routine work to get similar level performance that the automatic would get. And when the automatic solutions get better your code stays at the same level. Leaving out details means that an expert on them can get them better than you. As an author you main job is to say something interesting, to have a point.
In this way people have genuine cognitived diversity and not everyone work like the typical mind. Not spesifying your text to a narrow neuro/cognition type allows you to be polymorphic and be relevant for more people. It's also very differnt thing to provide hooks for differnt types to actively manage integration of your content than micromanage a very straight and narrow path.
In particular I got seriously stuck with "blizzard is -$100". This is a pretty alien way to express things to me. [...] Now I am tangled with problems with the auxillary tools and the point is obscured. [...] If we stayed at more abstract level then my disagremeent on the details would not similarly interfere.
But if you're stuck on how to model driving through the blizzard as having a utility-value of -$100, it means that you would have been stuck on any explanation of "avoid the sunk-cost fallacy" until you understand how that kind of utility-scoring works.
So the specific example was superior to the general statement in revealing where the remaining hole in your understanding is.
Now you can patch the hole yourself by looking up utility-scoring. Alternately, I could have anticipated that not all readers would know about utility-scoring, and explained that in an "earlier chapter", but it doesn't fundamentally undermine the value of specificity and mind-anchors to teach concepts better.
I have serious reservations that any experience that can't be traded on a market has any value that can accurately be dominated in dollars.
It triggers an impulse in me that this is a minor technical flaw that should be overlooked but it increases my cognitive burden and lowers my confidence that the author knows what they are talking about. Sticking your neck out is great. But making the thing long and the parts depend on each other makes errors compond.
In making a claim of "you would have been stuck on any explanation of "avoid the sunk-cost fallacy" until you understand how that kind of utility-scoring works" you are implying that it can not be explained without such scoring. I guess I couldn't in reality read the explanation of the fallacy on a clean slate because I already know about it beforehand. But science popularisers sometimes make misrepresentations in making curves straight. The good intention doesn't make up spreading misinformation.
I think this depends on your audience. If you want to explain to one person, look for Mind-Hangers. There's a chance they don't get it, but then you go to a replacement. This is faster than explaining from the ground up. If you use text to explain to many people, each Mind-Hanger is going to lose you that portion of your audience which isn't familiar with it. You'd have to design a conversation graph for people to follow, browsing through Mind-Hangers until they find one that fits them. This is faster for the reader than if you'd explained from the ground up, but slower for you. Reconciling the models so you can continue telling everyone the same stuff is an extra step that wouldn't be necessary in a one-on-one conversation. Keeping the models separate multiplies your work and hinders the economies of scale Web 2.0 grants us.