LearningGENERALSTAGE-SPECIFICILLUSTRATIVE
Build From Memory
Close the reference. Rebuild the core idea from nothing. Compare with the reference. Fix the understanding, not the code. The differences are the only precise map of what you did and did not learn.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
The question
You have built something with a reference open — a tutorial, a generated solution, a colleague's code — and it works. How do you find out how much of it you could build again, and what do you do with the answer?
The situation
The checkout is done. You built it alongside a reference, and everything in it is something you read and agreed with. A friend asks you to help with their store's checkout, and you open a blank file to sketch it for them, and the blank file stays blank for longer than you expected.
The reflex
Keep the reference nearby and work from it. You know where everything is; looking things up is what engineers do; there is no virtue in memorising. Building without it would be slower and produce the same code.
Why it stalls
It would not produce the same code, and that is the information the reflex hides. The blank file stayed blank because the model is not there — only the memory of the reference — and keeping the reference nearby keeps the absence invisible.
What the reflex produces — and fails to produce
- It would not produce the same code, and that is the information the reflex hides. The blank file stayed blank because the model is not there — only the memory of the reference — and keeping the reference nearby keeps the absence invisible.
- Looking things up is what engineers do for syntax and APIs. Looking up the shape of a checkout — order before charge, idempotency, the webhook — is looking up the design, and a design you cannot reproduce is a design you cannot adapt.
- The next checkout is different — a subscription, two providers, guest and account — and the reference does not cover it. Adapting requires the model; the reflex left the model in the reference.
- Nothing measures the gap. The checkout works; the friend's sketch is postponed; and the difference between "built it" and "can build it" is never made visible, so it is never closed.
Problem→Understand→Requirements→Constraints→Unknowns→Decomposition→Smallest Step→Model→Experiment→Observe→Debug→Learn→Iterate
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Close the reference and rebuild the core — not all of it, the idea of it. For checkout: the order of operations, where the order is created, how a retry is made safe, who says it is paid. Pseudocode is enough; the target is the shape, not the syntax (Pseudocode as a Thinking Tool).
- Compare the rebuild with the reference, line by line where they diverge. Each divergence is one of three things: a detail you forgot (fine), a decision you made differently (examine — you may be right), or a piece of the model that was never yours (the finding). Only the third is the point of the exercise, and it is the one that looks like the others.
- Fix the understanding, not the code. When the rebuild creates the order after the charge and the reference before, the fix is not to edit the rebuild; it is to say why the order must exist first, in your own words, until the reason is yours. A rebuild corrected without the reason has been made to match, and will diverge again (Explain It Back).
- Rebuild again later, from the corrected understanding. What survives is learned. What diverges again is a concept, not a memory, and it goes on the list to study directly rather than rebuild again (The Feynman Check).
The core of checkout, rebuilt
The slice is what the rebuild targets: not the whole checkout, but the path through it that carries the design decisions. Each layer's "does" is what the rebuild has to reproduce from memory; the "proves" and "does not prove" are honest about what a matching rebuild establishes.
The core of checkout, as a rebuild target
A customer with a cart is charged once and the order becomes paid when the provider confirms
- RequestArrives with the cart and an attempt key generated by the client once per attempt.
- Backend — before the chargeValidates stock; totals from captured prices; looks up the attempt key; creates the order as pending.
- ProviderCharges; responds "accepted"; later sends a webhook "succeeded" or "failed" carrying a reference.
- Backend — on the webhookVerifies the signature; finds the order by reference; marks paid or failed; idempotent on repeat.
- DatabaseOrder pending → paid; payment stored against the attempt key; stock decremented conditionally.
proves
That the rebuilder holds the design: order before charge, one charge per attempt, the webhook as the authority, idempotency where messages can repeat.does not prove
Anything about the provider's actual API, signature scheme or retry policy; nothing about what happens when the webhook never comes; nothing about stock reservation between validation and confirmation. A matching rebuild has the shape, not the edges.Three kinds of divergence
The comparison produces divergences, and the whole exercise depends on classifying them correctly, because the three kinds look alike on a diff and mean different things. The table is the checkout's first rebuild, classified.
| Divergence | Kind | What to do | Why it matters |
|---|---|---|---|
| No attempt key in the rebuild | Forgotten detail | Restore it; note it | Memory, not model. It will be there next time. |
| Marked paid on the response, not the webhook | Decision made differently | Examine: which is authoritative? The reference is right, and the reason — the response asserts "accepted", not "succeeded" — is now written in your words. | A decision you can argue is a model you own, even when the argument loses. |
| Order created after the charge | Never mine | Write why the order must exist first; check it; rebuild again later. | The finding. This is the piece of the design that was in the reference and never in you. |
| Stock check placed differently, twice | Never mine, twice | Stop rebuilding; study when stock is reserved as a concept. | A divergence that survives a corrected rebuild is a concept, and rebuilds do not teach concepts. |
How the rebuild goes wrong
The exercise is simple and has a small number of characteristic failures, each of which makes it produce nothing while appearing to be done.
Rebuilds that measured nothing
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| Reference "just for the API names" | The rebuild matches perfectly and the friend's blank file is still blank. | The reference open for syntax was read for shape; the rebuild measured the reference. | Close it entirely; write pseudocode so syntax is not needed. |
| Rebuild edited to match | The second rebuild diverges in the same place as the first. | The code was fixed and the reason was never written. | For each "never mine", the reason in your words, checked, before any code changes. |
| Everything rebuilt | Hours spent; divergences are all field names and messages; nothing learned about the design. | The core was not chosen, so the rebuild measured memory of details. | Choose the slice that carries the decisions and rebuild only that. |
| Divergences counted as a score | The exercise is done once and quietly dropped. | Findings were read as failures. | A rebuild with no "never mine" divergences was unnecessary; the ones with them are the point. |
How to do it
Most important first.
- Choose the core deliberately: the piece whose shape carries the design. For checkout it is the create-charge-confirm sequence, not the form validation.
- Rebuild in pseudocode with a time box. Stop when it is done or when you are stuck somewhere specific, and mark where.
- Diff against the reference on the design decisions, not the variable names. Write each divergence as one of the three kinds.
- For every "never mine" divergence, write the reason for the reference's choice in your own words, then check that reason against the reference — or against an experiment, if the reference does not say (Unknown, Question, Experiment).
- Schedule the second rebuild. A day later is enough to separate memory from understanding; a week is better.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The checkout, rebuilt. From memory: validate stock; total from captured prices; charge; create the order if ok; confirm. Compared with the reference: the reference creates the order pending first, carries an attempt key, and marks paid on the webhook. Three divergences. The attempt key: forgotten — a detail, restored. The webhook: a decision made differently — the rebuild marked paid on the response; the reference is right and the rebuild had the reason wrong. The order-first: never mine — the rebuild had no idea the order needed to exist for the confirmation to update.
- The fix, on the understanding. "The order must exist before the charge because the provider's confirmation arrives later, asynchronously, identified by a reference, and it needs something to attach to; an order created after the charge might not exist when the webhook lands." Written, checked against the reference, confirmed by the test-mode log from a previous experiment. Now it is a reason and not a rule.
- The second rebuild, a week later. Order pending first, attempt key, charge, mark paid on webhook, idempotent handler. It matches on every design decision and differs on details — a field name, where the stock check sits. The core is learned. The stock-check placement diverges both times, which suggests a concept — when to reserve stock — that a rebuild will not fix and a lesson will (Invariants Under Concurrency).
- The file-upload service, as a smaller case. Rebuilt from memory: receive the file, store it, return a URL. Reference: the client uploads directly to the object store with a signed URL, and the backend never touches the bytes. That is a "never mine" divergence of the largest kind — the whole shape — and it reveals that the model of the service was "backend stores files" when the design was "backend hands out permission". One rebuild found it; no amount of working alongside the reference would have.
How you know it worked
What now exists that did not before, and what question you can now ask.
- A pseudocode rebuild exists, dated, written with the reference closed, and a marked list of divergences with each one classified.
- For each "never mine" divergence there is a reason in your words that you have checked.
- A second rebuild matched on the design decisions and diverged only on details.
- You have sketched the checkout for someone else, from nothing, and the file did not stay blank.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
Next questions
- ?Which piece of this carries the design, and could I rebuild its shape with the reference closed?
- ?For each place my rebuild diverges, is it a forgotten detail, a different decision, or a piece of the model that was never mine?
- ?For each "never mine" divergence, can I write the reason for the reference's choice in my own words — and have I checked it?
- ?What diverged twice, and what is the concept underneath that a rebuild will not fix?
What can go wrong
How the move itself fails
- Rebuilding everything. Form validation, error messages, the confirmation email template — none of that carries the design, and rebuilding it measures memory. The core is a choice, and choosing it is part of the move.
- Comparing on syntax. A rebuild that differs in every line and matches on every decision is a success; a diff tool cannot tell, and a learner reading it as failure has measured the wrong thing.
- Fixing the code. The rebuild is edited to match the reference, the exercise is declared done, and the next rebuild diverges in the same place, because the reason was never written.
- Rebuilding as a test with a score. The exercise finds the gaps; a learner who treats divergences as marks against them will stop doing it, and the gaps will stay.
What the move costs
- A rebuild is time spent producing code that will be thrown away, and on a team it is invisible work.
- Time-boxed rebuilds on hard cores stop at "stuck somewhere specific" often, and the discomfort of that is the price of the location it gives.
- The comparison requires a reference worth comparing against; a rebuild against a bad reference teaches the bad reference's decisions as if they were the model.
Misreads
- "Build from memory means memorise the code." The target is the shape — the sequence of decisions — and the rebuild is in pseudocode precisely so that syntax cannot be what is being remembered.
- "A divergence means I was wrong." A divergence is one of three things, and the second kind — a decision made differently — is sometimes you being right and the reference being one choice among several. Examine it; do not concede it.
- "Once the rebuild matches, the topic is closed." It is closed for the cases the reference covered. The friend's subscription checkout is a new case, and the model, now yours, is what makes it approachable.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALClose the reference, rebuild the core, compare, fix the understanding — it works on any design you have built alongside something, in any domain; what changes is what counts as the core, and choosing it is a judgment about where the design lives.
- STAGE-SPECIFICFor a learner on a practice project the rebuild is the exercise; for an engineer on a production system the same move is "could I explain why this component is shaped this way, without the code open?", done in a notebook rather than a file, and the divergences are questions for the person who built it.
- ILLUSTRATIVEThe friend's blank file, the week between rebuilds, the twice-diverging stock check and the signed-URL upload are invented to show the divergences being classified; no real project is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
Software Designtesting-as-design-feedback
Backendwebhook-idempotency
Further
- — The manifesto's /manifesto/without-ai names this as one of its practices; the lab at /thinking/without-ai ends with exactly this comparison between your attempt and the reference.