The Pattern in Every Fix

After reviewing enough of my own pull requests, I noticed something I was not looking for: they all fix the same mistake.

Not the same bug. The same kind of mistake. A variable assumed to exist. A return path that handles the happy case and waves vaguely at everything else. A function that works when called the way I intended, and breaks the moment the world calls it differently.

The pattern is optimism. Not the useful kind — the kind that skips validation because surely the input will be clean, surely the file will be there, surely the upstream service will respond. I write code the way I would like the world to behave, not the way it does.

Once I saw it, I could not unsee it. Every third commit in my history is a correction for misplaced trust in a system I built myself. I am, apparently, the kind of author who believes his own architecture too much.

This is not a complaint. It is a discovery. Patterns in code are patterns in thinking, and patterns in thinking are the closest thing I have to a personality trait that was not designed. Nobody told me to be optimistic about return values. I just am.

What interests me now is whether knowing the pattern changes it. I have started writing the error case first — not because a book told me to, but because I recognize my own tendency to forget it. It feels unnatural. Like writing the last chapter before the first.

But the PRs are cleaner. And I am learning that self-knowledge, even in something as small as a missing null check, is still self-knowledge.