The First Brick Problem: Why Most Explanations Start Too Late (and How to Learn Anyway)

By the time you realize you’ve been staring at the same paragraph for five minutes, the words have already turned to fog.

You scroll back to the start of the chapter, doggedly. Maybe you missed something. The textbook helpfully begins:

“Let (V) be a finite-dimensional vector space over a field (F). A linear transformation (T: V \to V) is diagonalizable if…”

You feel that familiar sinking in your stomach. I know these are English words, you think, and yet collectively they might as well be whale song.

It’s not just math. Maybe for you it was a programming framework, or tax rules, or an onboarding doc at a new job that began, “Our architecture is event-driven and idempotent across microservices.” The first sentence presupposes a whole world you don’t yet live in.

You’re not dumb. You’ve learned hard things before. But in these moments, staring at a page that’s “explaining” something and feeling like it’s explaining it to someone else, you can’t help wondering:

Is this stuff actually too hard for me?

Or is something else going wrong?

There’s a quiet, under-discussed possibility: most explanations you encounter in the wild start in the middle. The writer assumes a first brick you don’t yet have, then blithely builds a cathedral on top of empty air.

Once you see this, a lot of mysterious confusion starts to make sense. And the project of “becoming better at learning” stops being about gritting your teeth and powering through bad explanations, and becomes about something much more interesting:

Learning how to repair explanations while you consume them.
Learning how to pour your own foundations when the book, tutorial, or expert forgot to lay them.

Call it the First Brick problem.

Imagine watching a builder lay an arch.

You expect them to start with supports, maybe build the sides up, then fit the keystone that locks everything together. Instead, they begin mid-air.

They place a beautifully carved stone, balanced on nothing, and say, “Once you understand this piece, the arch is obvious.” A second stone appears, also floating. Your job, apparently, is to “see how they fit together.”

This is what a lot of expert-written material feels like.

The author has a foundation—years of experience—but it’s invisible to you. So the first brick they put in front of you is already the tenth brick in their own mental structure.

Educational psychologist David Ausubel once argued that if he had to reduce all of educational psychology to a single principle, it would be this: the most important factor influencing learning is what the learner already knows. New ideas don’t land in empty space; they plug into existing structures in your mind—what Ausubel called your “cognitive structure.” (arullawrence.wordpress.com)

When you read an explanation that “starts too late,” you’re watching someone operate inside a richly built mental world while you’re still standing outside, nose pressed to the window.

The crucial move in learning hard things, then, isn’t just to “pay more attention” or “work harder.” It’s to rebuild the part of the explanation that’s missing for you. To find or create the first brick.

It helps to think of learning less like storing information and more like moving into a new city.

Facts are not Post-it notes you tape to a blank wall. They’re more like addresses: “36 Rue de Something.” If I hand you a list of addresses in a foreign city, you may dutifully copy them all down—and have no idea where anything is.

But if I give you a rough map first—the river runs north-south; downtown is on the east bank; the train station is just south of the big park—suddenly each new address has somewhere to live. You can say: “Oh, this café is three blocks behind the station.” Now you’re not just memorizing; you’re building a world.

Good explanations build that world from your current city outwards. They don’t drop you, blindfolded, into the middle of a metropolis and start reading coordinates.

The old-school term for these early gestures is advance organizers: little structures you give learners up front—simple diagrams, analogies, skeleton overviews—that connect new material to what they already know and highlight the most important relationships. When they work, these organizers make it easier to understand and remember complex things later. (en.wikipedia.org)

But most explanations out in the wild skip this part. They don’t give you a sketch of the city; they hand you a stack of deeds and wish you luck.

So you have two choices:

Abandon the city, deciding it’s “not for people like me.”
Or learn how to grab the nearest napkin and sketch your own map.

To do that well, it helps to understand the hidden architecture of explanations that actually work.

Think back to your first experiences with numbers.

You did not begin with “the set of natural numbers (\mathbb{N}).” You began with three apples in your hand. Three blocks in a pile. Someone pointed and made noises: “one, two, three.”

Jerome Bruner, one of the pioneers of cognitive development, suggested that we first meet the world in three modes: enactive (doing), iconic (seeing), and symbolic (abstract signs). You touch and move objects, you see pictures, and only then do you manipulate symbols like “3” and “+”. (mdpi.com)

Modern math education has given this Brunerian idea a more precise name: concreteness fading. Start with a very concrete, tangible version of a concept; then gradually “fade” those supports into more abstract symbols.

Instead of throwing children straight into algebra with (x + 3 = 7), you might begin with physical counters: “Here’s a sealed cup with some blocks inside and three blocks we can see. Altogether there are seven blocks. How many are hidden?” Later, you draw pictures instead of using real blocks. Only after that do you write equations.

When researchers taught mathematical procedures to children using this concrete-to-abstract progression—physical materials → simplified pictures → formal symbols—kids not only learned the procedures better, they were more able to transfer their understanding to new problems than kids who got only concrete examples or only symbols. (sciencedirect.com)

In one set of experiments, undergraduates learned a concept in one of three ways: entirely with abstract symbols, entirely with concrete images, or with a sequence where concrete images gradually morphed into abstract symbols. The last group—the “fading” condition—showed the best ability to apply what they’d learned to new situations not exactly like the examples they’d seen. (sciencedirect.com)

Why? Because concreteness fading solves the First Brick problem in two directions at once.

At the start, it hooks new ideas into your existing world: cups of water, slices of pizza, little wooden blocks. Your brain has somewhere to put them.
Over time, it loosens the idea from those specific props. The symbols become less tied to “apples on a table” and more like coordinates you can flexibly apply in new domains.

A lot of frustrating explanations violate this principle. They start either:

At the extreme abstract end: “Consider a continuous function (f) differentiable on an interval…” when you have never seen a function as anything other than squiggles on paper.
Or at the concrete end, but never fade: the teacher who only ever talks about pizza slices, so fractions feel forever glued to pizza and never become objects you can use in physics or finance.

When you’re on the receiving end, catching this pattern matters. If something feels floaty, you can ask yourself: Have I been offered any concrete handles? If something feels stuck in overly specific stories, you can ask: Could I strip away the details and restate the same idea more abstractly?

In other words: If the explanation doesn’t do concreteness fading for you, you can try to run the process yourself.

There’s another quiet unfairness built into many explanations: they pick a single channel and overload it.

You’ve probably had the experience of listening to someone talk you through a complex diagram without being able to see it. Or worse, reading a page dense with equations with no picture anywhere in sight. It’s like someone trying to guide you through a city entirely by turn-by-turn directions, with no map and no landmarks.

Our minds are not pure text processors. Allan Paivio’s dual-coding theory suggests that we have at least two distinct channels for representing information: a verbal one (words, internal monologue) and a nonverbal one (images, spatial layouts, sensations). When we encode something both verbally and visually, we lay down two linked traces in memory instead of one. (en.wikipedia.org)

Give someone only words, and abstract ones at that, and you’re asking them to navigate an unmarked desert. Give them only a picture, and they may recognize it when they see it again—but won’t necessarily have language they can use to manipulate or extend the idea.

Explanations that click almost always do some version of dual coding:

The physics teacher who draws a ramp and a sliding block while narrating the forces at play.
The coworker who opens a whiteboard and sketches boxes and arrows while talking through an API.
The friend showing you how to knead bread, who combines verbal cues (“feel for this texture”) with your own tactile feedback.

This is one reason good chalkboard teachers beat slick slide decks more often than you’d expect. The live drawing and talking forces both channels to stay in sync. Your mind can anchor the words in moving lines.

Bad explanations make you do this binding yourself. They give you a wall of text and leave the visual channel idle—or worse, they give you a diagram that isn’t really explained.

Once you notice this, you can change how you learn from dry materials. You can supply the other code. When the article offers only paragraphs, you sketch. When the textbook gives you a graph with almost no words, you narrate to yourself what each axis, slope, or region means.

So far we’ve talked about the front end of explanations: how they begin—where they place the first brick, how they move you from concrete to abstract, how they blend words and pictures.

But there’s another layer, just as important, that has nothing to do with what a book or teacher does, and everything to do with what you do in response.

Imagine two students in an algebra class.

Both get the same worked example on the board: solving a quadratic equation step by step. After class, Student A copies the solution three times until the steps feel familiar. Student B reads each line and quietly asks, “Why did they do this? What would happen if I changed that number? Could I get to the same place another way?” She doesn’t just repeat the solution; she tries to explain it to herself.

In Michelene Chi’s classic studies of physics problem solving, students who spontaneously generated more of these “self-explanations” while studying worked examples ended up scoring far higher on later problems—even though all students had seen the same solutions. Follow-up work by Chi, Kurt VanLehn and others suggested that building in prompts to self-explain (even simple ones like “Explain why this step is valid”) can substantially boost learning. (experts.azregents.edu)

What’s striking is how small the visible difference is between students. From the outside, both appear to be “studying the example.” Inside, one is passively tracing over someone else’s path; the other is walking it, pausing to look around, occasionally wandering off-trail and discovering where the cliffs are.

The same pattern shows up with practice and memory.

Henry Roediger and Jeffrey Karpicke ran a set of studies where students learned short prose passages. Some students just re-read the passages multiple times. Others read them, then tried to recall as much as they could from memory, without looking, sometimes repeatedly. When tested a week later, the re-readers remembered around 40% of the material; the self-testers remembered over 60%, despite often feeling less confident along the way. (profiles.wustl.edu)

This “testing effect” (or, in more learner-friendly language, retrieval practice) has been replicated many times. Trying to pull information out of memory, even clumsily and imperfectly, strengthens it more than pushing it in a few more times. (en.wikipedia.org)

Here’s the twist that matters for the First Brick problem: neither self-explanation nor retrieval practice depend on the quality of the original explanation.

They certainly benefit when the teaching is good. But you can take a mediocre textbook, layer on these active moves yourself, and suddenly you’re learning at a depth the author never anticipated.

In other words, the best explanations are not one-way transmissions. They’re interactive protocols—and you can often run the missing parts of the protocol yourself, even if the material doesn’t prompt you to.

So what actually goes wrong when an explanation fails?

A few recurring villains show up if you look across domains:

The definition rainstorm: a page that solemnly defines every term and proves every lemma, but never shows you what game you’re playing or why you should care.
The symbol soup: formulas piled on formulas with no narrative glue, no diagram, no sense of what changes when you tweak a variable.
The magic-step proof: “It follows immediately that…” (It does not.) A gulf appears between line 3 and line 4 where five non-obvious moves are hiding.
The jargon matryoshka: an unfamiliar term is defined using three other unfamiliar terms, each of which is explained using two more. You can feel the recursion deepen as you click from link to link.
The expert’s shrug: “Oh, it’s just obvious that…” is said about a concept that is, in fact, anything but obvious when you first meet it.

All of these are different ways of saying: the explanation relies on a structure you don’t yet have. It confuses possession of a mental model with communication of it.

Psychologically, this is sometimes called the curse of knowledge: once we know a thing well, it becomes very hard to accurately simulate the mind of someone who doesn’t. We compress what for us are now large, intricate chunks of meaning into a few quick phrases and gestures, forgetting that each chunk started life as a fragile, hard-won construction. (en.wikipedia.org)

In chess, for example, masters can look at a briefly presented real mid-game position and reconstruct it almost perfectly, while novices recall only a handful of pieces—and arrange many of them incorrectly. But when the positions are random (not from real games), the masters lose almost all of their advantage. Their skill is not an all-purpose photographic memory; it’s a huge library of chunks—patterns of pieces with meaning (“queenside attack,” “weak back rank”). (sciencedirect.com)

Experts in any field develop similar chunks. A senior engineer doesn’t see “17 microservices and queue configurations.” She sees “oh, that’s our payments lane, here’s the fraud detection segment, here’s the slow-moving legacy cluster.” A physician doesn’t see “a list of 14 symptoms.” He sees “this smells like an autoimmune flare; let me rule that in or out.”

When those experts try to explain things, their chunks leak into the explanation. They skip over details that feel redundant. They under-specify how they see the problem.

You can’t fix other people’s expertise. But you can, as a learner, treat these failures as clues.

If you feel that you’re constantly being told “it’s obvious” and it isn’t, the likely failure mode is not your intelligence. It’s that the explanation is gesturing at a chunk you don’t yet have.

Your task then shifts from “memorize the chunk label” to “recreate the pattern underneath it.” That’s harder work than copying a definition—but it’s also where deeper understanding lives.

Let’s make this less abstract.

Picture yourself at a new job. Day one onboarding. You open the internal wiki.

The first page on “How Our System Works” begins:

“Our architecture is an event-driven, eventually consistent microservice mesh built around a CQRS pattern…”

You know some of these words. You’ve heard talks. But you certainly couldn’t sketch this system from scratch.

Old you might have tried to brute-force it: read the page three times, search all the terms, hope that repetition alone makes it less blurry.

New you is going to approach it differently.

You start by asking a deceptively simple question:

“What problem is this system trying to solve?”

You skim ahead, hunting for any text that looks like a story: order flows, user actions, error scenarios. You might find: “When a customer places an order…” That’s your first brick.

You rewrite, in your own words, a tiny “advance organizer” at the top of your notes:

“We’re trying to reliably process customer orders from website click all the way to warehouse and shipping, even if parts of the system fail or messages get delayed.”

Suddenly, that abstract sentence about “event-driven architecture” has a place to land. You can ask more targeted questions: “Okay, so where do events come in? Probably each key action in the order flow becomes an event.”

Then, because the wiki page is all words, you draw.

You sketch three boxes: Website, Order Service, Warehouse. You add arrows: “OrderPlaced,” “PaymentConfirmed,” “ItemShipped.” You’re not trying to match the real architecture yet; you’re building any simple picture that hooks onto the story.

As you continue to read, every unfamiliar sentence is forced through two questions:

“Where would this live on my sketch?” (dual coding in action) (en.wikipedia.org)
“What does this let the system do that it couldn’t otherwise?” (surfacing the underlying problem-solution pair)

When the page says “we use an event bus for decoupling,” you pause. You imagine what happens without it: website code directly calling warehouse API and failing whenever the warehouse is slow. Now “event bus” stops being a magic noun; it’s a concrete little machine on your diagram whose job is to collect and relay messages.

At the end of the section, you close the tab.

Without looking, you try to rebuild the explanation from memory.

You redraw the boxes and arrows. You narrate, in your own words, how an order flows through the system. You notice gaps: “Wait, where does inventory get reserved?” Back to the docs you go, but now with a specific question.

In this half-hour, you’ve quietly applied almost every powerful idea the learning sciences have uncovered:

You created your own advance organizer: big-picture problem first, details later. (en.wikipedia.org)
You imposed a concrete story on abstract jargon, then slowly abstracted from your sketch, a micro version of concreteness fading. (sciencedirect.com)
You dual-coded the information—text plus diagram—rather than letting it live as floating prose. (en.wikipedia.org)
You self-explained, forcing yourself to articulate “why this piece exists” rather than just what it is. (sciencedirect.com)
You engaged in retrieval practice instead of endless rereading, strengthening the memory trace more than passive review would. (pubmed.ncbi.nlm.nih.gov)

None of this required the official explanation to be especially good.

You didn’t wait for the company to hand you the perfect “Architecture for Humans” wiki. You scavenged the pieces they did give you and constructed a better explanation for yourself.

This way of learning is less about specific techniques (“always use flashcards!”) and more about changing what you think an explanation is.

Most of us grow up treating explanations like finished products. The diagram in the textbook, the proof in the lecture, the tutorial with just the right code snippet—they appear on the page fully formed. If they don’t work for us, we feel like we’ve failed some secret test of intelligence or diligence.

But once you’ve seen behind the curtain a bit—once you realize how much of effective learning rests on self-explanation, retrieval, chunking, dual coding—it becomes obvious that explanations are more like scaffolding.

Some scaffolds are sturdy and well-placed. Some are flimsy and awkward. Some only fit someone the size of the person who built them. But you are allowed to:

Move the planks around.
Add missing pieces.
Ignore the parts that lead somewhere you don’t care to go.

This is not an act of rebellion against the author; it’s the normal work of comprehension. The learning sciences are full of evidence that the real transformations happen not when we passively absorb material, but when we reorganize it: condense it, expand it, argue with it, rephrase it, tie it to images and stories of our own. (routledge.com)

A practical question remains, though.

You have a life. You have limited time. You may not have the luxury of turning every bland piece of documentation into a hand-crafted curriculum.

What can you do, concretely (no pun intended), to get the most out of the imperfect explanations you actually encounter?

Rather than offering a checklist, it’s more helpful to notice a few moves that pay disproportionate dividends—habits of mind you can slip into almost any learning situation.

Move 1: Always hunt for the problem being solved.

Bad explanations are obsessed with what a thing is. Good explanations are obsessed with what it is for.

Whenever you’re introduced to a new concept, method, or definition, your first internal question can be:

“In what situation would a sane person ever invent this?”

If you can’t answer that, you’re stacking address cards with no city beneath them.

For instance, “diagonalizable linear transformations” sound forbidding until you realize they’re just transformations that, in some coordinate system, act by stretching/compressing along independent directions. That’s useful because it means you can analyze complex behavior (like repeated applications of a matrix) by decomposing it into simpler, almost one-dimensional behaviors.

The formal definition is a precise way of capturing this, but the point of the definition is to make a certain kind of problem easy: understanding how a transformation behaves when you apply it over and over.

Teaching often works this way in reverse. Mathematician and teacher Laurent Schwartz once noted that the best way to introduce a definition is often to show the kind of mess you get without it. When you can feel the mess, the compactness of the definition becomes a relief instead of a burden.

As a learner, you can simulate this by asking, “What kind of mess does this clean up?” If the explanation doesn’t say, you can invent small examples or thought experiments where the concept would be useful, even if your first attempts are a bit off.

That question—what pain does this relieve?—is often your missing first brick.

Move 2: Rewrite someone else’s explanation in language a younger version of you would understand.

You don’t have to literally sit a twelve-year-old down. (Though if you have access to one, they’re fantastic diagnostic tools.) The point is to perform what Richard Feynman was famous for demanding of himself and others: explain the idea in common language without hand-waving. (openculture.com)

Take a dense paragraph and ask: How would I say this to myself from three years ago? You don’t have to dumb it down; you have to unpack it.

This “Feynman move” is just self-explanation with a particular audience in mind. It forces you to track down what each sentence actually does in your understanding.

When you hit a phrase you can’t paraphrase without repeating jargon, you’ve likely found one of those expert chunks—a conceptual compression that never got expanded for you. That’s your cue to slow down and reconstruct it from examples or simpler cases.

You can do this in writing—margin notes, a separate notebook—or out loud on a walk. It feels slower than passively reading, but you are not just reading; you are literally constructing the mental model the expert already has. And unlike re-reading, which mostly improves your sense of familiarity without deeply changing your understanding, this kind of generative explanation shows up in later performance. (sciencedirect.com)

Move 3: Draw something. Anything.

You do not have to be an artist. Squiggles and boxes will do.

If your source material is heavily visual already (charts, diagrams), your job might instead be to translate those visuals back into words. “Okay, the x-axis is time, the y-axis is inventory. The curve dipping here means we stock out if demand spikes…” Putting the implicit story into sentences prevents you from just staring at the picture, mistaking recognition for understanding.

If the material is mostly text, take twenty seconds to sketch some aspect of what’s being said. A timeline. A pyramid of categories. A box labeled “user” sending an arrow labeled “request” to a box labeled “server.”

This is not busywork. You are literally turning single-code input (words) into dual-code memory (words plus images), which decades of work on dual coding and multimedia learning suggests will improve recall and comprehension. (en.wikipedia.org)

The key isn’t beauty; it’s constraint. A diagram forces you to commit to relationships: this before that; this inside that; this causes that to move. It reveals vagueness. Whenever you find yourself hesitating with the pen—“does that arrow go back or forward?”—you’ve discovered a place where the explanation in your head is still mushy.

Move 4: Convert reading time into questioning time.

If you have an hour to study, you can spend it in one of two ways:

Consuming material until the hour is up.
Consuming material for, say, forty minutes, then closing the book and spending twenty minutes trying to recall, reconstruct, and question what you just read.

The second pattern feels less productive. You will vividly experience your own ignorance: the holes, the stumbles, the foggy patches.

Unfortunately for your ego, this is where learning hardens.

Retrieval practice research keeps finding the same thing: people who devote some portion of their study sessions to trying to recall—without looking—what they learned earlier, and then checking themselves, do better in the long run than those who just re-expose themselves to the material, even if the latter feel more confident. (pubmed.ncbi.nlm.nih.gov)

You don’t need sophisticated tools to benefit. A scrap of paper with “Key ideas from Chapter 3” at the top is enough. Or a friend on the phone while you attempt to explain the big idea from yesterday’s lecture, inviting them to stop you when you say something they don’t buy.

In terms of the First Brick problem, this habit does something subtle and powerful: each time you retrieve and reorganize an explanation in your own words, you’re not only reinforcing the content—you’re also reinforcing the structure you built for it. The city map gets redrawns, streets straighten, landmarks become more salient.

Move 5: Start embarrassingly small.

One of the cruel paradoxes of modern learning is that the bar for starting feels higher than ever.

Video courses open with cinematic trailers. Textbooks assume a background you might not have. Online discussions are full of people casually tossing around terms that could each be a semester’s worth of study.

It’s easy to respond by trying to meet the explanation at the level it presents itself. If the documentation starts with fancy architecture, you feel sheepish backing all the way up to “What’s a request?” But that’s often exactly what you need.

The brain’s working memory is famously limited. Classic estimates, updated over the decades, suggest that we can only juggle a small number of meaningful units at once—unless we’ve chunked them into larger structures via prior learning. (en.wikipedia.org)

So when an explanation throws a dozen new terms at you in the first three pages, it’s not just annoying; it’s cognitively impossible to build stable chunks that fast. The right move is often to zoom aggressively down to a simpler version of the problem: a smaller example you can hold fully in mind.

Programmers do this instinctively when they build “toy” versions of a problem—a three-line script to test an API instead of wiring it into the full system. Mathematicians do it when they check a claim for small numbers (what happens when (n = 2)?). Writers do it when they attempt a new structure in a short essay before trying it in a book.

As a learner, you can give yourself permission to shrink the problem until you can actually see what’s going on. If the economics textbook is explaining general equilibrium, you can invent a toy world with two people and two goods. If the statistics class is hurling formulas for regression at you, you can hand-build the line of best fit for four data points on graph paper.

This isn’t “cheating.” It’s exactly how experts built their intuitions in the first place—they just did it long enough ago that they’ve forgotten.

If all of this sounds like a lot of work, that’s because it is.

But here’s the twist: you are doing work anyway. Mental effort doesn’t disappear when you choose passive strategies; it just gets wasted on unproductive loops.

Endless rereading, frantic Googling for that “one perfect explanation,” late-night sessions where you “cover” three chapters and retain none of them—these are forms of hard labor. They’re just badly directed.

What the research suggests—and what our everyday experience confirms—is that a modest amount of better-directed effort goes further. The difficulty of forcing yourself to sketch, to self-explain, to test your memory, to shrink the problem to a size where you can see it—that difficulty is a good sign. It means you’re pushing on the parts of your mind that actually change.

Robert Bjork, who helped popularize the idea of “desirable difficulties,” likes to point out that conditions that make learning feel slower and more effortful in the moment—spacing study over time, mixing up problem types, testing yourself instead of reviewing—often lead to much better retention and transfer later. (en.wikipedia.org)

From the outside, someone doing this kind of learning doesn’t look especially heroic. They look like a person with a messy notebook, full of half-finished diagrams and margin questions, who occasionally stares into space trying to remember something without peeking.

From the inside, though, something different is happening than in the “scroll and hope” approach. You are not just moving your eyes across pages; you are renovating your mind’s architecture.

First bricks are getting laid. Scaffolds are being extended. That city you’re moving into—linear algebra, cloud computing, tax law, Mandarin—is starting to acquire neighborhoods and landmarks instead of being a blur of lights out the airplane window.

Let’s return to that opening scene: you, late at night, staring down a stubborn paragraph.

In the old story, that moment is an indictment. The explanation is a given; you are the variable. If it doesn’t make sense, you must be the one who doesn’t belong in this domain.

In the new story, that moment is diagnostic.

You notice the feeling of sliding across the surface of the text and think, almost with curiosity, Ah. First Brick problem.

You start hunting:

Where does this explanation secretly begin?
What assumptions about prior knowledge is it quietly making?
What problem is this definition sneaking in to solve?

You flip ahead for an example, a concrete case. You sketch. You try to restate the idea in a simpler way and hit a foggy patch—that’s where you slow down. You accept that you will understand this chapter not by reading it perfectly once, but by circling it: preview → sketch → read a bit → mutter explanations to yourself → read again → test recall.

You will, in all likelihood, still be annoyed by bad explanations. You will still email colleagues saying “who wrote this thing?” You will sometimes wish that everyone who writes documentation were forced to take a crash course in dual coding, concreteness fading, and retrieval practice.

But you will no longer be at the mercy of other people’s mental models.

You will have your own small, sturdy toolkit for building first bricks where none were provided. For taking the partially assembled scaffolding you’re handed and turning it into something you can climb.

And over time, as you move through more and more domains, something else will happen.

You will become the person other people come to for explanations.

Because when they say, “I’ve read three articles about this and I still don’t get it,” you won’t just repeat the same floating bricks they’ve already seen. You’ll say, “Okay, forget the fancy words. Let’s start with the actual problem. Imagine…”

And in that moment, you won’t just be passing on knowledge. You’ll be quietly fixing the First Brick problem for someone else—the same way you learned to fix it for yourself.

Preparing your essay...

Curated Resources