Writing to Learn: Explaining It in Your Own Words
If you cannot explain an idea simply, you have not finished learning it. A short written explanation is an honest test.
On this page
"I understand it" is easy to say and difficult to test. Recognition is comfortable. A sentence looks familiar, and the reader nods. Writing removes that comfort. A short explanation demands an order, a set of connections and specific claims, and the places where those are missing show up on the page. For someone learning alone, that makes writing one of the most reliable checks available.
Why writing exposes gaps
Writing forces sequence. To explain why a gradient points toward steepest increase, the writer has to say what a gradient is, what a small change in an input does to the output, and how those pieces combine. Each sentence depends on the one before, so a missing step becomes a visible jump. Recognition hides these jumps because the sentence read earlier already filled them in.
The symptoms are specific. Vague nouns such as "the process" or "the thing" appear where a precise term belongs. Sentences begin with "this means" and restate the previous sentence. A paragraph that feels finished contains a claim that cannot be justified when someone asks why. Those are the spots to return to.
There is also a difference between explaining and summarizing. A summary repeats the source in shorter form and can be produced without understanding it. An explanation has to say why one step follows from the one before, and that is the part that tests understanding. If the text could have been produced by copying the source, it is probably still a summary.
The explain-it routine
The routine has five steps, and it takes about as long as a careful paragraph.
- Write the question in one line, in plain words, as a newcomer would ask it.
- Write an answer for one named reader, without consulting notes.
- Mark every term that could not be defined without looking it up.
- Check one claim with a small worked example, such as a two-number calculation or a few lines of code.
- Cut the answer to half its length, keeping only what the reader needs for the next step.
The cutting step matters most. Long explanations often hide gaps behind extra words, and forcing the text shorter makes the gaps visible again.
The routine works best on a question you actually have, not on a topic in general. Writing about gradient descent in general produces a survey. Writing about why a particular update made a model worse produces a question with a checkable answer, and that is far more useful.
Write for a specific reader
Choose one reader and keep them in mind throughout. A colleague from another discipline, a friend who builds bridges, and a version of yourself from six months ago each assume different things. The reader decides which terms need defining and which steps can be skipped. "Explain it to a beginner" is too vague, because a beginner in one field may already know the mathematics another field would need explained.
The trade-off runs between two errors. Writing for someone too simple produces explanations that are technically wrong, because the simplifications have crept in. Writing for an expert hides the gaps behind jargon. A reader with a name is the best guard against both.
A useful exercise is to write the same explanation twice, once for each of two readers, and compare the results. The differences show which assumptions were doing the hidden work.
Turn the gaps into the next session
Keep a running list of claims that were written down but could not be justified. This list is more useful than general notes, because it names the exact thing to study. "I do not know why the update is scaled by the learning rate" gives tomorrow's session a clear target. "I need to learn more about optimization" does not.
Each gap should also have an exit condition. A gap is closed when a worked example reproduces the claim, or when a short test confirms it. Without that condition the list only grows, and it becomes a source of worry rather than a plan.
Publish short notes, carefully
Publishing an explanation invites correction, and correction is the point. A short note with a clear claim draws specific feedback. Keep notes brief, and state what was checked and what was not. Name the sources used, so a reader can verify the claim without relying on memory. A summary of someone else's work should not be presented as an original finding.
Avoid publishing notes that claim more than was tested. A confident error in public is harder to repair than one kept in a private notebook.
Before publishing, reread the note as if you were the reader who knows least about the topic. Any sentence that depends on an unstated assumption should either be explained or removed.
Practice by rewriting a known explanation
To practice, choose an explanation read recently that seemed clear at the time. Close the source and write the explanation again in your own words, for a named reader, within a fixed length. Then open the original and compare. Mark each place where the new version is vague, wrong or missing a step. For each mark, write one question and decide how it would be answered. Finally, review a short explanation written by someone else, judging it on three points: whether each claim is supported, whether the assumptions are stated, and whether the example would catch an error. The aim is not a polished essay. It is a note that holds up when a follow-up question arrives.
