// August 25, 2026
Reading Error Messages Like After-Action Reports
3 min read
// related
// August 25, 2026
3 min read
// related
The best meeting the Army ever taught me had no slides, no agenda deck, and — this is the important part — no blame. It's called the After-Action Review, and it runs on four questions:
What was supposed to happen. What actually happened. Why the gap. What we change next time.
Rank goes quiet in a good AAR. A private can say the plan failed at step two, and if that's where it failed, that's what goes in the review. The whole discipline rests on one premise: the truth about what happened is more valuable than anyone's comfort about it, including the commander's. Units that run honest AARs get better. Units that run polite ones repeat the same mistakes with better paperwork.
It took me years to notice I'd been handed a debugging methodology.
An error message is a report from the field: at this line, in this file, expectation and reality parted ways. It's specific, it's timestamped, and it has no opinion of you whatsoever.
That's not how most of us read it. We read it as an accusation — and the moment we do, debugging turns into defense. You skim the message instead of reading it, because reading it slowly feels like listening to criticism. You investigate everything except what it names, because the named thing implicates code you wrote. I documented a version of this in last Friday's field note: a refactor polished enough that I expected a sophisticated failure, when the first line of the first error had already named the dumb, true problem — a function I'd written twice.
Run it as an AAR instead and the ego has no seat at the table. What was supposed to happen: the function returns a user. What happened: undefined. Why: the report says the lookup ran before the session loaded. What changes: fix the order — and then the real AAR move, the one that separates it from ordinary debugging — what makes this class of mistake harder to repeat. A test. A type. A note. The AAR doesn't end at "fixed." It ends at "changed."
This discipline is older than the manual. Seneca, two thousand years ago, described his evening routine: "When the light has been removed and my wife has fallen silent, I examine my entire day and go back over what I've done and said, hiding nothing from myself, passing nothing by."
That's an AAR. Same structure, same rule — hiding nothing, and, as he says elsewhere in the same passage, without fear of the review, because the point is correction, not punishment. The Stoics get quoted a lot for endurance, but this is the piece I'd keep: they reviewed themselves like professionals, nightly, and then went to sleep. The review was the discipline. The self-flagellation we usually substitute for it is just ego wearing a judge's robe.
Which brings me to the version of this that has nothing to do with code.
A bad week ends and the instinct is to issue a verdict: I blew it. I'm off track. I'm not built for this. Verdicts feel like accountability. They're actually the opposite — a verdict closes the case before the review happens, and nothing gets learned. I've written before that bad days lie about output; they lie about causes too.
So run the four questions on the week, blame withheld. What was supposed to happen: five workouts, the module finished. What happened: two, and half. Why the gap — the actual why: sleep fell apart Tuesday and everything downstream followed. What changes: the shutdown time gets defended first, because the review says everything else hangs off it. Case closed, lesson filed, week over.
Notice the week just became data. That's the whole trade.
Errors, evening reviews, rough weeks — all field reports. The report is neutral. Blame is optional, and expensive. The fix is the mission.
Read the message twice. Ask the four questions. Keep the lesson, return the ego to storage, and go back out the gate.