How I reason about systems.

Wait for three. Two instances of a pattern feel like coincidence. Three feel like a rule. Abstracting at two builds the wrong generalization — you're encoding what two things have in common, which is usually less than what you think. At three, you've seen enough variation to know what the abstraction actually needs to handle.

I ask: what does this make harder to change? The reversibility of a decision matters more than its correctness in the short term. A reversible wrong decision costs one correction. An irreversible one can compound into a system property. Under time pressure, I prefer the option that preserves the most future optionality — even if it's slower now.

When the requirement encodes a solution rather than a problem. 'We need a queue here' is a solution. 'We can't lose these requests' is a problem — and it might be solved by a queue, or by synchronous retries, or by idempotency. I push back to find the actual constraint, then design to that constraint rather than its proposed solution.

Adversarial. Complexity is debt in disguise. Every layer of indirection, every configuration option, every conditional branch is a cost that future engineers pay. My default is deletion and simplification. When I can't simplify, I make the complexity visible — documented, tested, isolated — so it can't spread.

As a specification. The way a system fails tells you what it believes about itself. A system that fails catastrophically believed it wouldn't fail. A system that fails gracefully was designed by someone who knew it would. I design failure paths as first-class features — explicit fallbacks, known degraded states, observable signals when things go wrong.

Observable, reversible, and understood. A feature is done when you can tell whether it's working without reading the code. It's done when you can roll it back without a crisis. It's done when a new engineer can read the system and understand why the decisions were made. 'Working' is necessary but not sufficient.