Write code like the next reader is exhausted

Somewhere in the future, someone will open my code at 2am with a production incident burning and no context beyond what's on screen. That person is the audience I write for. Frequently, that person is me.

What the exhausted reader needs

Obvious control flow. No clever one-liners that require a whiteboard. If a comprehension payoff is small and the cleverness is large, the cleverness loses.

Errors that say what happened. Not "Error". A message naming the operation, the input, and the reason. Six months of debugging experience compressed into one string.

Comments that explain why. The code says what it does. The comment says why it exists, what it protects against, or why the obvious alternative was rejected. That's the part the reader can't reconstruct alone.

Consistency over brilliance. If this codebase does X one way, doing it that way here is kindness. Every novel pattern taxes a tired brain.

The test I apply

Before shipping, I read the diff once and ask: if I woke up to a pager at 2am pointing at this file, could I understand and fix it while half-asleep? If the answer is no, the code isn't done. Elegance is optional. Recoverability isn't.