What a lost game teaches me that a won game doesn't

I almost always review my lost games. Much more rarely my wins. It isn't forced discipline, it's that the two don't teach the same thing, and one of them lies more easily than the other.

A win can hide a bad decision

Winning a game where I took an unjustified risk, simply because my opponent didn't find the refutation, leaves a false impression: the result validates a piece of reasoning that didn't deserve it. If I don't replay the game with a critical eye, that bad reflex stays intact, ready to resurface against an opponent who will find the flaw.

A loss forces you to find where it actually broke

Losing forces a question that a win lets you dodge: at which exact move did the position tip over? It's almost never the last move, the one that seems to have lost everything at once. It's usually much earlier, a decision that looked reasonable at the time and whose consequences only showed up ten moves later. Finding that precise moment is the exercise that matters, not the final result.

The parallel with a code review

The same reflex applies to a production incident or a code review gone wrong: the real work isn't noticing that something broke, it's tracing back to the specific decision, often unremarkable at the time, that made the breakage possible. A postmortem that stops at "the deployment failed" teaches nothing; a postmortem that traces back to an architecture decision made three months earlier teaches something reusable next time.

What I actually do

After every tournament game, I spend a few minutes identifying the move that tipped the game, not simply the last one before the loss. It's uncomfortable, because it forces me to acknowledge a lapse in judgment rather than bad luck. It's also the only method that's let me improve year after year: not by playing more games, but by understanding better why the ones I lose, I lose.