Explaining something to a peer shows what you do not know

Thousands of programmers spend part of each day answering strangers’ questions for nothing, and in May 2010 Jeff Atwood tried to explain why. He had launched Stack Overflow with Joel Spolsky in 2008, and in a post on his blog, The Vast and Endless Sea, he listed what he thought kept people answering. The sentence above was one item on that list. The others were about reputation, community and the pleasure of helping, but this one explains why the habit pays off for the person doing it.

The mechanism is ordinary. Knowing how to do something and being able to explain it are different states, and the gap between them is usually invisible until someone asks. Writing an answer forces the steps into order, and the step that cannot be written down clearly is usually the one the writer never understood. A programmer who has used a library for years may find, halfway through an explanation, that one of its behaviors has always been a guess.

The word “peers” matters. A beginner accepts an explanation; a peer tests it. On Stack Overflow an answer sits in public next to others, collects votes and comments, and can be edited by people who know better. The same thing happens in a code review, where a senior engineer explaining a design choice to a colleague often discovers that the choice was habit rather than reasoning. The audience talks back, and that is where most of the learning happens.

The idea has limits that Stack Overflow itself exposed. Speed gets rewarded: a quick answer that is roughly right tends to collect votes before a slower, careful one appears, and a confident wrong answer can sit near the top for a long time. Teaching can spread errors as efficiently as it spreads understanding, and the person teaching may never find out.

Teaching the same material repeatedly also stops being practice. Someone who answers the same twenty beginner questions every week becomes very fluent at those twenty and learns nothing new. Mastery needs problems at the edge of what a person can do, and the questions peers happen to ask are not always there. A good explainer and a strong practitioner are also not the same person; some people explain beautifully and build poorly.

For a small team the practical version is modest and useful. Have people explain their own work to each other on a regular schedule, especially the parts they consider obvious, and treat every awkward pause as a gap worth filling. Atwood’s point was about individual programmers, but it works for founders too: explaining the business to a sharp peer is one of the quickest ways to find the part of the plan that has never been thought through.