It's 11pm on a Friday. Something broke in production. The person who gets paged is the same person who built the thing six months ago, except now they're tired, they've had a long week, and they can't remember why they made half the decisions they made.
They open the codebase. Or the runbook. Or the process doc. Whatever it is, they need to understand it right now, under pressure, with no warmup.
This is the moment that reveals whether you built something durable or something clever.
Clever systems work beautifully when the person operating them is rested, focused, and has context. That's the morning version of you. The one who just had coffee. The one who remembers why the abstraction exists, how the edge cases got handled, why the configuration file is organized the way it is.
The morning version of you thinks every decision was obvious.
The 11pm version of you can't find the config file.
The gap between those two people is where most system failures actually live. Not in the architecture diagrams. Not in the test coverage. In the distance between the person who designed the system and the person who has to operate it while exhausted.
There's a filter I run on every decision now — code, process, curriculum, project plan, anything. One question.
Can the tired version of me still operate this?
Not the sharp version. Not the caffeinated version. Not the version that just spent three days deep in the problem. The tired version. The one who got pulled off something else. The one who's context-switching. The one who started this job two weeks ago and has never seen this system before.
If the answer is no, simplify until it is.
That's not a compromise. That's the design target. You're not building for the best-case operator. You're building for the realistic one. And the realistic operator is tired more often than they'll admit.
This applies well past code.
A capital project with a filing system only the project manager understands fails the Tired Test. A curriculum that requires the person who wrote it to teach it fails the Tired Test. A business process that needs a hero to run it on a bad day fails the Tired Test. An onboarding doc that assumes context the new hire doesn't have fails the Tired Test.
The pattern is always the same. Someone built for themselves, at their best, and forgot that the next person — or the future version of themselves — would not be at their best.
The instinct, especially in technical work, is to reach for sophistication. More layers of abstraction. More configuration options. More flexibility for hypothetical future needs. It feels like building quality in. It's usually building fragility in.
Sophistication is a luxury of being rested. It becomes a liability the moment you're not. The system that survives isn't the most elegant one. It's the one that still makes sense when the person operating it has been awake for eighteen hours and just wants to fix the thing and go to bed.
Simple systems survive tired engineers. Clever systems require fresh ones. And you don't get to pick which version shows up.
Build for the tired one.