Explain It Back
Explain it in your own words, draw it, apply it to a case it was not explained with. Three checks that turn "I read it and it made sense" into evidence — and that fail, usefully, exactly where understanding stops.
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.
You have read an explanation — of webhooks, of idempotency, of a data model — and it made sense. How do you find out whether you understood it or only followed it, before the difference costs you?
You read about how a payment provider confirms a payment: the response, the webhook, the signature check, the idempotent handler. It was clear. You closed the page. An hour later, writing the handler, you cannot say whether the order should be marked paid on the response or on the webhook, and you are fairly sure the page said.
Reread it. The information was there; a second pass will fix it in memory. Understanding is a matter of exposure, and if once was not enough, twice will be.
The second pass produces the same feeling as the first — it made sense — and the same gap an hour later. Following an explanation exercises recognition; producing one exercises recall; and the handler needs recall.
- The second pass produces the same feeling as the first — it made sense — and the same gap an hour later. Following an explanation exercises recognition; producing one exercises recall; and the handler needs recall.
- The page said something about the response and the webhook, and it made sense at the time because the page carried the structure. Away from the page, the structure is gone, and what remains is the memory of having understood.
- Rereading does not locate the gap. The whole page is reread, including the parts you did understand, and the part you did not is not marked in any way, so it slips past again.
- The handler gets written by imitation — matching the shape of the page's example — and works in test mode and is wrong in a way that appears the first time the webhook arrives before the response does.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Explain it back in your own words, without the source open. Not a summary — an explanation, as if to someone who has to build the handler. Where the words come easily, you understand; where you reach for the source's phrasing, or stop, you have found the boundary (The Feynman Check).
- Draw it. A sequence — customer, backend, provider, and the arrows in order — forces every question the prose let you skip: what arrives first, what carries what, what happens if the arrows cross. A drawing you cannot finish has found a gap that a paragraph you could reread hid (Thought Experiments).
- Apply it to a case the explanation did not use. The page explained the happy path; explain what your handler does when the webhook arrives twice, or before the response, or for an order that does not exist. Application is the only check that catches an explanation understood correctly and too narrowly (Edge Cases From Examples).
- Treat each failure of the three checks as a specific unknown, not as "I need to reread". "I cannot say what happens if the webhook arrives first" is a question with an experiment; "I did not get it" is a feeling with a page.
Following against explaining
The comparison is the same page read two ways. In the worse column the reading ends with a feeling; in the better column it ends with a paragraph, a drawing, two cases and one experiment. The second reading took longer and produced the handler; the first produced a second reading.
Read the page; it made sense; closed it. An hour later: response or webhook? Reread the page; it made sense; closed it. Wrote the handler by matching the example's shape. It works in test mode. It marks the order paid on the response, and nothing handles a webhook that arrives first.
Read the page; closed it; explained it in a paragraph and stopped at "response or webhook". Drew the sequence; could not label the response arrow. Experiment: charge in test mode, log both. The response says "accepted", the webhook says "succeeded". Handler: pending on response, paid on webhook, idempotent on the webhook, correct when it arrives first.
The better column turned the reading into a question with an experiment, and the experiment produced the model the handler needed. The worse column produced recognition twice and a handler that encodes the example's happy path.
The question the checks sharpened
The hesitation was "response or webhook?", and that is already better than most questions a reader has after a page. The ladder shows it sharpened further, to the form that has an experiment and a design decision on the other side of it.
why The best form makes the experiment obvious (log both, read what each asserts), makes the design decision explicit (the webhook is authoritative; the response moves the order to pending), and names the three cases the handler must survive. The vague form has no experiment; the better form has one but hides the three cases.
What the drawing left unknown
The checks do not end in understanding; they end in a board — what is now known, what was being assumed, and what is still unknown as questions with experiments. This is the payment-confirmation board after the three checks; the handler was written from the known side and the unknowns became the next afternoon.
- ✓The synchronous response asserts "charge accepted"; the webhook asserts "payment succeeded" or "failed".
- ✓The order is created pending before the charge and marked paid only by the webhook, which is authoritative.
- ✓The webhook can arrive first or twice; the handler looks up by provider reference and is idempotent.
- ~The webhook always arrives eventually. Unverified — the provider's documentation on retries has not been read.
? Webhook never arrives.
becomes If no webhook arrives within a reasonable window, does the order stay pending forever, and is there a way to ask the provider for the payment's state?
experiment Charge in test mode with the webhook endpoint disabled; find the provider's query endpoint; write what a reconciliation job would do.
? Signature check.
becomes What exactly is signed, with which secret, and what should the handler do with a webhook that fails the check — reject silently or alert?
experiment Send a test webhook with a modified body; observe the failure; decide the response and log it.
? Failed after pending.
becomes When the webhook says "failed", what happens to the pending order and the reserved stock?
experiment Trigger a test-mode failure; walk the order and stock through it on paper first, then run it.
Every unknown here is one the page could not have raised, because the page explained a mechanism and the checks built a model. Models have edges; mechanisms do not.
How to do it
Most important first.
- After reading, close the source and write the explanation in a paragraph. Time it; the hesitation, not the errors, is the data.
- Draw the sequence with numbered arrows. Every arrow carries a label saying what is in it; an arrow you cannot label is the gap.
- Pick two cases the source did not cover and write what happens in each. If the answer is "the page did not say", the page told you a mechanism and not a model, and the model is what you need.
- Turn each failure into a question with an experiment, and run the experiment before rereading. Usually the experiment answers it and rereading becomes confirmation (Unknown, Question, Experiment).
- Do the three checks again a day later, briefly. What survives a day is understood; what does not is the next thing to draw.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Payment confirmation, explained back. "The backend asks the provider to charge; the provider answers immediately with a result; separately, the provider later sends a webhook saying the payment is confirmed; the backend checks the webhook's signature and — " here the hesitation: should the order be marked paid on the response or the webhook? The explanation stops at the exact question the handler needs, which is what the check is for.
- Drawn. Customer → backend: checkout. Backend → provider: charge. Provider → backend: response (result: ok, pending?). Provider → backend: webhook (payment succeeded). Labelling the response arrow forces the question the prose skipped: is the response "charged" or "charge accepted"? That is the unknown, and it has an experiment: charge in test mode, log both messages with timestamps, read what each says.
- Applied to a case the page did not use. Webhook arrives before the response: the handler looks up the order by the provider's reference, finds it pending, marks it paid; the response then arrives and must not un-mark it. Webhook arrives twice: the second must find "already paid" and do nothing — which is idempotency applied to a place the page discussed idempotency only for the charge. Two cases, two design decisions, both surfaced by application.
- The chat app, same three checks on "read state". Explained back: fine until "what is stored when a user reads a message on one device" — hesitation. Drawn: a message, a user, and an arrow labelled "read" that goes between them and not on the message — the drawing corrected the model. Applied: two devices, one reads; the other must show read; therefore the state is per user per message, and the drawing was right (What Information Changes Over Time?).
How you know it worked
What now exists that did not before, and what question you can now ask.
- A paragraph exists in your words, written with the source closed, and the places where it stopped are written as questions.
- A drawing exists with every arrow labelled, and any unlabelled arrow has an experiment beside it.
- At least one case the source did not cover has been worked through, and it produced a design decision.
- The handler you wrote afterwards handles the webhook-first and webhook-twice cases, and you can say why from the drawing.
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.
- ?Can I explain this, source closed, to someone who has to build it — and where exactly do I stop?
- ?Can I draw it with every arrow labelled, and which arrow can I not label?
- ?What does it do in a case the explanation did not use — and did the explanation give me a model, or only a mechanism?
- ?For each place a check failed, what is the specific question and the experiment that answers it?
What can go wrong
- Explaining back with the source open. The words come from the page and the check passes; it has measured the page.
- The three checks applied to everything read. A paragraph on a library's configuration options does not need a drawing; the checks are for mechanisms you will build on, and applying them to reference material is ceremony.
- The drawing done as decoration — boxes and arrows with no labels — which cannot fail and therefore cannot find anything.
- The failures treated as a verdict rather than a location. Hesitation at "response or webhook" is the check succeeding; a learner who reads it as "I did not understand the page" and rereads has thrown away the one piece of information the check produced.
- Three checks after every important reading cost more than the reading did, and on a mechanism you will use once the reading alone may be the right investment.
- Hesitation is uncomfortable, and the checks manufacture it deliberately; some learners avoid the checks for that reason and lose the location they provide.
- Applying to a case the source did not cover can produce a confident wrong model where the source was silent; the experiment is what keeps application honest, and it costs time.
- "Explaining it back means summarising it." A summary reproduces the structure of the source; an explanation reproduces the mechanism from your own model. The test is whether someone could build from it.
- "If I can explain it, I understand it." If you can explain it, draw it and apply it to a new case, you understand it as far as that case. The third check is the one that limits the claim, and it is the one most often skipped.
- "The checks replace the experiment." They locate the gap; the experiment closes it. A hesitation at "response or webhook" is answered by logging both in test mode, not by a better paragraph.
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.
- GENERALExplain, draw, apply works on any mechanism in any domain — a consensus protocol, a rendering pipeline, a tax rule; what differs is which check fails first, and that is information about the mechanism.
- SIMPLIFIEDThree checks is a teaching model. Real understanding is checked continuously and informally — a question from a colleague, a bug that should not have happened — and the three named checks are the deliberate version of what a good engineer does by reflex when something "made sense" too easily.
- ILLUSTRATIVEThe payment page, the hour, the webhook-first case and the chat app's read state are invented to show the checks failing usefully; no real provider or documentation is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's /manifesto/review is the same practice pointed at a generated answer: explain it back, draw it, apply it to a case it did not use, and see where it stops.