Bratha

Part 2.0 — Mental Models for Learning

17 min read

This is Part 2 of 5 in the Learning & Skill Acquisition Series

  • Part 1 — Foundation:
  • Part 2 — Mindset (2 sub-articles):
  • Part 3 — Behavioural (2 sub-articles):
  • Part 4 — System:
    • Part 4.0: The Learning System (Obsidian + Excalidraw, structure vs context, the publish workflow)
  • Part 5 — Chemistry:

Table of Contents

One method you apply to any domain, not ten tactics you pick from

The point of Part 2.0 is not to give you a buffet. ==It’s to give you one method, in four steps, that you apply to any new domain* you decide to learn.* When you’ve used it twice, you’ll notice it converging on the same shape every time: history → your narrative → root → practice. Tactics (spaced repetition, Pomodoro, flashcards) are inside the method, not alternatives to it. If a tactic doesn’t slot into one of the four steps, you don’t need it.

Why a four-step method, not a list of tips

Most “how to learn” writing is a list of tactics. Spaced repetition, the Feynman technique, interleaving, dual-coding, Pomodoro, mind-mapping. Every one of those is a real thing that works in the right place. None of them tells you what to do on Monday morning when you sit down with a new domain and don’t know where to start.

The reason is that tactics are not a method; they’re moves inside one. Pomodoro is when you practise, not what you practise. Spaced repetition is how you retain, not how you build a map in the first place. A new learner with a pile of tactics and no method is exactly the picture from Part 1.0: someone collecting Pokémon cards with no map of what each one is for.

A method has to do three things:

  • Tell you what to do first in any new domain (not after you’ve already understood it)
  • Tell you in what order (so you don’t end up memorising vocabulary you don’t have context for, or chasing edge cases before you have a centre)
  • Be applicable to anything (a new language, a new programming language, a new accounting standard, a new sport, a new section of the law)

The four-step method below does those three things. It works because it mirrors the shape of how a working understanding actually gets built: you start with why this exists, then you retell it in your own words, then you anchor it on a centre everything else relates to, and only then do you grind reps on it until you can do it without thinking.

The four steps

The method

  1. Learn the causation history first. Why does this topic even exist? Who built it, and what problem were they solving?
  2. Build your own narrative. Retell the storyline in your own words. A model, a framework, even a mnemonic.
  3. Anchor with a root note. Identify the one concept everything else clings to, and place every new piece in relation to it.
  4. Deliberate practice. Iteration and trial-and-error against an honest error signal. (The mechanism is in Part 2.1.)

The order is the strategy. Skip step 1 and your map has no centre of gravity; skip step 2 and the map is somebody else’s; skip step 3 and every new piece floats; skip step 4 and the map never becomes a skill (just trivia). Each step builds the substrate for the next one. The temptation is always to jump to step 4 immediately (“I’ll just practice and figure it out as I go”), and the result is what Part 2.1 calls cargo-cult practice: motion without an error signal.

Step 1: Learn the causation history first

Before any technique, any term, any framework: why does this topic exist at all?

Every field of human knowledge is a response to a problem. Someone, at some point, had a problem that the existing tools couldn’t solve, and the field is the accumulated set of attempts to solve it. If you don't know the problem the field was built to solve, you can't tell which parts of it are load-bearing and which parts are historical accident.

Worked examples:

  • Double-entry bookkeeping. It exists because single-entry bookkeeping made it trivially easy to lose track of money in a multi-party trading economy. The “every transaction has two sides” rule isn’t a quirk; it’s a check against the failure mode of the previous system. Once you know that, every accounting concept (the trial balance, the general ledger, even why modern accounting tech is structured the way it is) is just an evolution of “how do we keep both sides honest at scale?”
  • Biology. Most of what’s taught was discovered, not designed, and the discovery story is the actual structure of the knowledge. Knowing that Mendel was counting pea plants because the heritability question was open in a particular way, and that DNA’s structure was solved because that opened a new question, gives you a map of biology as a sequence of questions answered. Memorising the answers without the questions gives you trivia.
  • Programming. Every language exists in response to what the previous languages couldn’t do well enough. C exists to write systems software portably; Python exists because writing C for everything was wasteful; modern JavaScript exists because the original JavaScript wasn’t designed to do most of what people now do with it. The history isn’t decoration; it tells you what each language is for and what it isn’t.

The rule for step 1, before you do anything else with a new field:

The history move

==Find one good account of why the field exists.== A long-form article, a chapter, a documentary, a conversation with someone who lived through the relevant change. Spend an hour or two there. Don’t take detailed notes; just absorb the shape. Who had the problem, what did they try, why did the current approach win?

This costs you almost nothing in time and changes the geometry of everything you read after it.

Step 2: Build your own narrative

The next move is to retell the history (and the basics that came with it) in your own words. Not somebody else’s framework. Yours.

This is the step almost everybody skips, because it feels redundant: “I already understand it, why would I rewrite it?” The answer is from Part 1.0: a model you didn't draw yourself is one you can only memorise, not revise. When the inevitable update comes (because reality pushed back, or because you learned the next layer), a model someone else drew for you has to be discarded; a model you drew yourself can be edited.

The narrative can take several shapes. Use whichever one fits the domain:

  • A storyline. “The field started here, hit this problem, the dominant response was X, then Y came along because of Z, and that’s where we are now.” Best for fields that genuinely have an arc (history, economics, a programming language, a discipline of medicine).
  • A model. A simple diagram or framework that shows the relationships between the main pieces. Best for fields that have a strong structure (accounting, organic chemistry, the architecture of a software system). The Excalidraw canvas in Part 4.0 is the home for this.
  • A mnemonic. A short, memorable handle that compresses the main pieces. Best when the field has a small fixed list at its core (the eight anabolic pathways, the four humours, the seven habits, the five love languages, the six cognitive pathways). A mnemonic isn’t lazy; it’s compression. The shorter and more memorable, the more cognitive room it frees for the next layer.

The test for a good narrative

Can you tell it, out loud, to a colleague who doesn't know the field, in under five minutes, without notes? If you can, the narrative is doing its job. If you can’t, you don’t have a narrative yet; you have a pile of facts that you’re hoping is one.

Step 3: Anchor with a root note

By step 3 you’ve got a history and a narrative. Now place a stake in the centre: the one concept everything else in this field clings to. That’s the root note (sometimes called the central concept, the load-bearing idea, the “if-you-only-know-one-thing”). Everything subsequent goes into the map by its relationship to the root.

Worked examples:

  • AI. The root, in the current generation, is the LLM. Almost everything in the current AI conversation (RAG, fine-tuning, prompt engineering, agents, evals, multimodality, RLHF, context windows) is some relationship to that root. Knowing the root means every new term you meet, you can immediately ask “how does this relate to the LLM?” and place it.
  • Accounting. The root is the accounting equation (assets = liabilities + equity). Every concept in financial accounting is a refinement of, an exception to, or a consequence of that equation.
  • Strength training. The root is progressive overload. Every program, every split, every periodisation scheme is a different way of organising progressive overload.
  • This blog’s Fit series. The root is the Fit-vs-Healthy split. Every subsequent article (training, pharmacology, biomarkers) routes back to that one distinction.

Once the root is named, two new things become possible:

  • New information has a place to go. When you read about retrieval-augmented generation, you don’t store it as a free-floating fact; you store it as “a way of giving an LLM access to context outside its training data.” It costs almost no cognitive overhead because you’re not memorising a new island; you’re hanging an ornament on an existing tree.
  • Wrong information becomes detectable. When something doesn’t fit the relationship to the root (“this AI advice doesn’t seem to actually care about what an LLM is”), you have a way to notice it. Without a root, every claim looks equally plausible because there’s nothing to test it against.

One root per field, not three

The instinct is to pick two or three “really important” concepts and treat them as co-equal roots. Don’t. Pick one, even if it's slightly arbitrary, and force everything else to relate to it. A single root creates a hierarchy; multiple roots create a swamp. If two candidates feel equally central, pick one as the root and treat the other as the most important child of that root.

Step 4: Deliberate practice

The first three steps build a map. Step 4 turns the map into a skill. This is where the field stops being something you can talk about and starts being something you can do.

The dangerous shortcut here is to skip steps 1–3 and jump straight to “I’ll learn by doing.” That’s not deliberate practice; that’s flailing. Practice without a map produces motion, not learning. You burn hours, accumulate scar tissue, and end up with a bunch of confident habits that the field’s actual structure would have warned you against. (The classic shape is the self-taught programmer who can ship features but can’t read a codebase, or the self-taught lifter who’s strong on three lifts and broken on five.)

The mechanism of deliberate practice (iteration, trial-and-error, the focus-hours principle, the plateau diagnostic, the 90/10 of practice itself) is the entire subject of Part 2.1. Here’s the one-line bridge:

What step 4 looks like, in one sentence

Practise the specific sub-skills your map says are load-bearing, against an honest error signal, in conditions close enough to the real thing that the practice transfers.

Every word in that sentence is doing work, and Part 2.1 unpacks all of them.

Kaufman’s effective-learning list, mapped onto the four steps

Josh Kaufman’s First 20 Hours and Personal MBA compress decades of skill-acquisition research into ten principles. They’re useful, and they’re easy to misuse: people treat them as a checklist to run alongside a learning project, when actually eight of the ten slot cleanly inside the four-step method above. Here’s the mapping:

Kaufman’s principleBelongs in
1. Research the skill (and related topics)Step 1 (causation history)
2. Jump in over your headStep 1 (you can’t research the history of a thing you haven’t touched)
3. Identify mental models and hooksStep 2 (your narrative)
4. Imagine the opposite of what you wantStep 2 (a narrative that includes its own failure mode is sturdier)
5. Talk to practitionersStep 4 (the reality-check loop)
6. Eliminate distractions in your environmentNot Part 2 — lives in Part 3.0
7. Use spaced repetition and reinforcementStep 3 (anchoring new context to the root over time)
8. Create scaffolds and checklistsStep 3 (the root and its immediate children are the scaffold)
9. Make and test predictionsStep 4 (reality-check + deliberate practice’s error signal)
10. Honor your biologyNot Part 2 — lives in Part 1.0 (rest), 3.0 (day), 3.1 (consolidation), 5.0 (chemistry)

The two principles that don’t fit (#6 environment, #10 biology) are exactly the two that get their own Parts in this series. That’s not a coincidence; the body and the environment are the two things you can’t think your way through.

Supporting models (after the four steps)

These don’t replace the four steps; they’re tools you reach for inside them when the relevant step is harder than usual.

The 80/20 inside any domain

Most fields have a small handful of load-bearing concepts that explain most of the field’s behaviour, and a long tail of detail that explains the rest. The load-bearing concepts are the ones the root note ties together. Before you add any detail in step 3, identify the 5–10 load-bearing concepts and make sure they're solid. Adding detail to a field whose load-bearing concepts are vague is the express route to a confidently-wrong map (the precision trap from Part 1.0).

A quick test: name the load-bearing concepts of a field you know well. If it takes you more than ten seconds for each, your own map of that field has the load-bearing parts in good shape. If you have to think hard about what’s load-bearing, you’ve been adding detail to a fuzzy centre.

First principles vs. analogy

Two ways to break a topic down, each with a different cost:

  • First principles. You break the topic down to its atoms and rebuild it from scratch. Expensive in time, very high in understanding. Best when the existing analogies are wrong (the way “the brain is a computer” is wrong) or when you’re trying to do something genuinely new.
  • Analogy. You lift a structure from a domain you already know and apply it. Cheap in time, lower in understanding. Best when the analogy is close enough (most fields have at least one close cousin you can lift structure from) and you need a working map quickly.

The cost-benefit usually favours analogy first, then first-principles on the parts the analogy breaks. Pure first-principles on a field where good analogies exist is a vanity project; pure analogy on a field where the cousins are misleading is a recipe for the precision trap.

The “explain it to a colleague” test

The fastest way to find the holes in your own map is to try to explain it to someone who doesn’t know the field. Not to teach them; to test yourself. The places you stumble, hand-wave, or say “it’s complicated” are the places your map is fuzzy. (This is what step 2 is fundamentally doing: the narrative is the test, not just the artefact.)

A useful variant: pretend the colleague is a smart fifteen-year-old. The constraint is brutal because it strips out every jargon shortcut you’ve been using to avoid understanding. If you can't explain the load-bearing concepts to a smart fifteen-year-old, you don't understand them yet; you've memorised them.

Pre-mortems and inversion

Before you commit to the map you’ve built, ask: how would I know if this map is wrong? Specifically: what’s the failure mode I should expect to see if my model is off? Write the failure modes down. When you encounter them later, you’ll recognise them immediately instead of explaining them away.

The matching move is inversion: study how people fail at this skill before studying how they succeed. Failure modes are often more informative than success stories, because successful practitioners frequently don’t know what they’re doing right (lots of survivorship bias), but unsuccessful practitioners can usually tell you exactly where things went wrong (and the same failures repeat across them). For most fields, what not to do is a denser signal than what to do.

Part 2 Takeaways

What to carry forward

  • The four-step method is the whole game. Causation history → your own narrative → root note → deliberate practice. Apply in that order, to any new domain.
  • Step 1 (history) is the cheapest, highest-leverage hour you’ll ever spend on a new field. It changes the geometry of everything you read after it.
  • Step 2 (narrative) is the step most people skip, and the one that makes the difference between a map you can revise and a map you can only memorise.
  • Step 3 (root note) gives every new piece of information a place to go. One root per field. Force everything else to relate to it.
  • Step 4 (deliberate practice) is the subject of Part 2.1. Without it, the map never becomes a skill; without steps 1–3, the practice is just flailing.
  • Tactics live inside the method, not alongside it. Spaced repetition, Pomodoro, flashcards: if it doesn’t slot into one of the four steps, you don’t need it.
  • Use the supporting models when the relevant step is hard. 80/20 for finding load-bearing concepts, analogy then first-principles for breaking a topic down, the “explain to a colleague” test for finding the holes, pre-mortems and inversion for stress-testing the map.

Your Mindset Task List

Apply the method to one real domain this week

  • Pick one domain you’re learning right now. Not a hypothetical one. The next ACCA paper, the new framework at work, the language you’re picking up, the skill you’re trying to install.
  • Spend one hour on step 1. Find one good account of why this field/skill exists. Read it for the shape, not the detail.
  • Try to draft step 2 in 30 minutes. Write down, in your own words, the storyline of the field, in under 500 words. Notice where you stumble; those are the places to push on next.
  • Name the root note. One concept everything else clings to. Even if it’s slightly arbitrary, pick one.
  • Read Part 2.1 next. It’s the depth on step 4, the part of the method that actually turns the map into a skill.

Sources & references

Disclaimer

The four-step method is a structure for thinking about learning, not a guarantee of mastery. Skills genuinely take time; this method shortens the time wasted on the wrong things, but the focused hours still have to happen. The method that doesn't get used beats no method by zero.

Graph View

Backlinks