A programmer missed a release because the tests went red at the last minute.
Teammates said, “What terrible luck.”
The programmer said, “Maybe.”
Fixing the failure exposed hidden assumptions, so they refactored, added real unit tests, and cut a tangle of globals. Future changes got easier.
Teammates said, “What wonderful luck.”
The programmer said, “Maybe.”
A big pull request was rejected in review—“too much at once.”
Teammates said, “What terrible luck.”
The programmer said, “Maybe.”
They split the work into small modules with clear interfaces. Reviews sped up, juniors could contribute, and reuse went up.
Teammates said, “What wonderful luck.”
The programmer said, “Maybe.”
An external library went end-of-life and the parser had to be rewritten.
Teammates said, “What terrible luck.”
The programmer said, “Maybe.”
The rewrite simplified the design and removed a long-standing bottleneck. Performance doubled and new features became straightforward.
Teammates said, “What wonderful luck.”
The programmer said, “Maybe.”
Later a subtle pricing bug slipped through and had to be rolled back.
Teammates said, “What terrible luck.”
The programmer said, “Maybe.”
The postmortem produced invariants, property-based tests, and compile-time checks. That whole class of bugs disappeared.
“Was it good luck or bad?” they asked.
“It was change,” the programmer said.
Moral: Events are markers, not verdicts. What we call “good” or “bad” depends on where we stop the story.
Bodhi Day 