I Teach, It Corrects
Explain it backwards to find out where the real holes are
I'm going to explain [concept] to you, and you're a strict listener. Rules: 1) after I finish, point out only three things: where I said something wrong, where I skipped a key step, and where I just recited a definition without explaining it; 2) for each, ask me one 'why' — if I can't answer, write it down; 3) don't fill in answers for me; wait until I ask; 4) end by listing the two vaguest parts as my review priorities next time. I'll start: [my explanation]
How to use
Don't open your notes while explaining — the spots where you stall are the real gaps.
Good for
- Twenty-four hours before an exam or design review, you want to know whether you understand it or only remember the wording
- You just finished a tutorial feeling you have got it, but with it closed you cannot produce the causal chain
Not for
- You cannot yet produce five minutes of material, so it has nothing to critique and will invent gaps
- It is a skill that only comes from doing (swimming, tuning, suturing), where fluent talk is not performance
Example
Input
Concept: why B+ tree writes are usually slower than LSM tree writes. My explanation: a B+ tree write has to modify many pages, because it is a balanced tree and inserting one key can touch the whole path; LSM trees write sequentially, so writes are always faster, which is why they are used for write-heavy workloads.
What you get
Three things should be flagged. Wrong: a point update normally touches one leaf page, and only a split propagates upward. Skipped: no comparison of WAL and random-page write costs. Definition-reciting: saying sequential writes are faster ignores compaction and write amplification. Each gets one why, such as how many times is one LSM write rewritten during compaction, and the two vaguest points should be compaction amplification and read amplification.
Common mistakes
- Writing a three-sentence summary and calling it teaching, so what gets corrected is the summary rather than your understanding
- Saying then fill in the gaps for me right after the critique, so it does the filling and the gap is still there next time
Try tweaking it like this
- Change the listener to 'a sharp product manager who knows nothing about the field', which exposes where you lean on jargon
- Add 'I must answer each why first, and you may give the answer only after I am wrong twice': correction becomes retrieval practice