the hardest skill in engineering isn't building things. it's knowing when to stop building.
i've watched projects die from over-engineering more often than under-engineering. the code was immaculate. the abstractions were elegant. the test coverage was pristine. and the product never shipped because the team couldn't stop perfecting the foundation.
the 80% trap
there's a well-known principle that the last 20% of the work takes 80% of the time. what's less discussed is that the last 20% often doesn't matter. not because quality doesn't matter. it does. but because the gap between "good enough" and "perfect" is usually invisible to users and costly to engineers.
i rebuilt a deployment pipeline three times before shipping it. the first version worked. the second version was cleaner. the third version was beautiful. nobody noticed the difference except me. and i'd burned two extra weeks.
diminishing returns feel like progress
the insidious thing about over-engineering is that it feels like productive work. you're writing code. you're solving problems. you're improving the system. the feedback loop is positive. each change makes the code measurably better. but "better" in a way that compounds on a graph nobody is looking at.
real stopping power comes from asking a different question. not "can this be improved?" the answer is always yes. instead ask "does improving this change the outcome?" if the outcome, the user experience, the reliability, the team's ability to work, stays the same, then the improvement is a luxury. not a necessity.
practice stopping
i've started deliberately practicing stopping. when i finish a feature and feel the pull to refactor, i make myself wait a week. if the refactor still feels necessary after a week of living with the code, it probably is. if i've forgotten about it, it wasn't.
most of the time, i forget about it.
shipping is a muscle. so is stopping. the engineers i admire most aren't the ones who write the most beautiful code. they're the ones who know exactly how much beauty the situation requires, and not an ounce more.