// Start simple · lesson 06

The over-engineering reframe, or thoroughness versus avoidance

There's a real tension inside this whole track, and I don't want to pretend it away. Systems thinking, seeing the ripple effects, architecting for what could go wrong, that's a genuine strength, and it gets dismissed as "over-engineering" by people who can't see the failure modes it prevents. Sometimes the thorough version is the right version and the simple version is naive. So how do you tell disciplined thoroughness from avoidance dressed up as rigor?

The line, I've found, is where the effort lands. Thoroughness aimed at the invariants, the properties that must hold, the failures that would actually hurt, the security boundaries, is the real thing. That's rigor, and it's exactly the systems-thinking strength that's rare and valuable. Effort aimed at the implementation, polishing internals nobody will see, abstracting for cases that don't exist, gold-plating the parts that already work, is avoidance. Same amount of care, pointed at the wrong target.

How do you catch yourself doing the avoidance version?

Ask what you're protecting against, and whether it's real. Thoroughness has a named threat: "if this drifts, a customer sees another customer's data," "if this fails, we lose the audit trail." Avoidance can't name the threat, because there isn't one; it's just discomfort with shipping, wearing the costume of standards. If you can point at the specific bad outcome your extra work prevents, it's rigor. If the honest answer is "it just felt unfinished," you're polishing to avoid the risk of exposure, and no amount of polish resolves that, because the fear isn't about the code.

The reframe, held honestly

Over-engineering is thoroughness pointed at what matters and procrastination pointed at what doesn't. The skill isn't doing less care. It's aiming your care at the invariants and the failure modes, where thoroughness compounds, and starving the implementation details, where it just delays. Be relentless about what could actually break. Be ruthless about everything else.

The takeaway: thoroughness on the invariants is a strength, thoroughness on the implementation is avoidance, and the tell is whether you can name the real threat your extra work prevents. Aim the care; don't just spend it.