Explain something out loud monthly

Why this is the best test

Reading produces recognition — the comfortable feeling of "yes, I know this". Recognition is not the same as knowing, and it collapses the moment you have to generate the explanation yourself.

Speaking exposes the gap in about ninety seconds. You get three sentences in, reach for the why, and find you only ever had the what. That failure is the entire value: it is precise, immediate, and tells you exactly what to go and read.

This is why "explain it out loud without notes" is the pass criterion on every item in the brush-up tracker.

Four formats, in order of effort

1. To another engineer. Best, because they interrupt with the hard question. Ten minutes at lunch, no preparation. "Can I explain something I just figured out?"

2. To a non-engineer. Harder and more revealing. You cannot lean on jargon, so you have to actually have a model. If you cannot explain database indexing to a friend using a phone book, you understand the mechanism but not the idea.

3. Written, published. A short blog post or an internal wiki page. Writing is slower than speaking, which means more time to notice the sentence you cannot finish. Publishing adds just enough accountability that you fix it rather than hand-wave.

4. Recorded, to nobody. Three minutes into a phone recorder, then listen back. Feels ridiculous, works completely. The listening-back is where you hear yourself say "and then it sort of handles that", which is the sound of a gap.

Do it well

• No notes. The whole mechanism depends on retrieval. Reading your notes aloud is just reading.
• Start from the problem. "Before indexes existed, finding a row meant reading every row." Explaining what a thing solves forces the model; explaining what it is permits definitions.
• Use one concrete example throughout. Abstract explanations can be assembled from vocabulary; a worked example cannot.
• Note where you stall. Do not push through it — the stall is the result you came for. Write it down, look it up afterwards, and re-explain in a week.
• Invite the "why". Ask your listener to interrupt with "why?" twice. Most understanding is one layer deep and the second "why" finds the floor.

Monthly is enough

This does not need to be a practice. Once a month, on the most interesting thing you learned that month, is enough to keep the habit alive and to catch the biggest gaps.

If you want a natural trigger: every time you fix a non-obvious bug, explain the root cause to someone. You have the context loaded, the explanation is genuinely useful to the team, and the debugging is only actually finished when you can say why it happened.

The side effect

The engineers who get promoted are usually not the ones who know the most. They are the ones who can make other people understand things — in design reviews, in incident calls, in documentation. This habit trains exactly that, and the technical benefit is almost a bonus.

Prove you know it

Pick the last thing you learned from this tracker and explain it out loud right now, to a person, a recorder, or an empty room. Time how long before you stall. Whatever you were reaching for when you stalled is your next reading assignment.