Building training material typically follows six steps: pick a topic, research material, design the structure, write, review, polish. A common shortcut is to skip steps 2 and 3 — research and structure — and start writing directly, on the reasoning that "it's already all in my head." That shortcut tends to be expensive: it produces a stall on concrete examples early on, and a structurally wrong draft that surfaces later, often forcing two or three rewrites of the same section.
TL;DR: the urge to skip prep doesn't scale with topic difficulty — it scales with confidence, which means the riskiest moment is exactly when someone feels most ready.
Why the shortcut feels safe
On a topic someone has taught or written about for years, the "finished shape" of the material feels like it's already sitting in their head. Skipping step 2 (gather concrete examples) and step 3 (decide the order a first-time reader needs them in) then feels less like cutting corners and more like just getting started.
The trouble is that "knowing the topic" and "having a reader's on-ramp for the topic" are different assets. The first is already stored. The second — a concrete example that lands, an order a stranger can follow — has to be actively built, not recalled. Skipping the research step quietly skips the search for that on-ramp, not just "the topic."
Where the shortcut breaks down
Two failure modes show up reliably once someone skips straight to writing on a familiar subject.
The first surfaces early: reaching for a concrete example and finding nothing ready to use. The line under "here's an example" stays blank. What's stored is "things I want to explain," not "an example that makes a reader go, oh, I see." Those look similar from the inside but aren't the same material — one lives in the writer's head, the other has to be found or constructed.
The second surfaces later, usually on a full read-through: the order turns out to be wrong. Writing without a structure tends to produce "the order I'd say it out loud" — most interesting point first, background pushed to the end — rather than "the order a first-time reader needs it in." A reader hitting paragraph three runs into a term nobody has explained yet. The writer can read straight through, because they already hold the whole map; a new reader can't.
The cost that stacks up
These two failures compound rather than add. Fixing the order usually means the examples have to move too, and fixing the examples exposes more order problems. It's common for a section written this way to go through two or three rewrites before it holds together — rewrite #1 stalls on missing examples, rewrite #2 tries to fix the order and the whole thing falls apart structurally, rewrite #3 finally holds.
Spending roughly an hour on research and 30 minutes on structuring up front tends to cut total writing time by a wide margin compared to skipping straight to the draft. The step that gets skipped to save time is often the most expensive part of the process — not the writing itself. Whatever confidence buys in speed at minute zero, it tends to charge back with interest once the first stall hits.
The same pattern in code
This mechanism isn't specific to writing training material. It shows up in software the same way: skipping the spec or design phase on a feature the team already knows well, because "we've built ten of these already." Restated as pseudocode, the two paths look like this:
# skip design, write straight into implementation
def build_feature(requirements):
# "I know this codebase, I don't need to spec it out"
code = write_implementation_directly(requirements) # ~0 min spent on design
# an edge case surfaces that the skipped design phase
# would have caught — a wrong assumption baked into the structure
if not handles_edge_case(code, requirements):
code = rewrite(code) # rewrite #1
if not handles_edge_case(code, requirements):
code = rewrite(code) # rewrite #2
return code # arrives at the right shape, several rewrites later
# spec and design first
def build_feature_v2(requirements):
spec = research(requirements) # time spent up front
structure = design(spec) # time spent up front
return write_implementation(structure) # typically far less total time than the version above
Familiarity with a codebase produces the same miscalibration as familiarity with a topic: the felt sense of "I already know how this goes" substitutes for the actual work of pinning down assumptions before committing to an implementation, and the gap surfaces as one or more expensive rewrites.
The rule worth extracting
The reflex to skip prep doesn't fire on hard topics — people already brace for those, take notes, slow down. It fires specifically on topics they're fluent in, because fluency feels like completion.
Knowing the material and having the reader's on-ramp for the material are two different assets. One is stored. The other has to be actively built — and skipping that build is what "I already know this" quietly disguises.
The gap that causes the rewrite isn't "I don't understand this well enough." It's that the shape held in the writer's head — the finished-feeling shape — is not the same object as a structure a stranger can follow. That gap tends to be invisible from the inside, which is exactly why it usually surfaces only after a rewrite or two.
A habit worth trying
This pattern is common enough that "I already know this one" is worth treating as a warning sign rather than a green light to skip ahead. Before writing the first line — in training material or in code — it's worth pausing on two questions: are the concrete examples or edge cases actually collected, not just recalled? And is the order built for someone encountering this for the first time, rather than the order it would come out in if said out loud?
Sho Naka (nomurasan) builds training material and ships code, and writes about common failure patterns in both.
This article was adapted and translated with AI assistance from a Japanese original. Responsibility for the technical accuracy of the content rests with the author.
Top comments (0)