Premature Articulation: 12 Phrases That Kill Good Code

I have been on both sides. Early in my career, I deployed "it depends" like a
shield. A junior would ask for guidance, and I would say "it depends," then stare
at my screen until they left. I was lazy. The phrase killed the conversation.

Years later, I was the recipient. A colleague demanded underscores on my private
TypeScript variables because "it is best practice." I asked why. The compiler
already enforced privacy. The answer was the same four words. No reasoning. Just
a slogan. I have also weaponized DRY against a teammate, insisting two similar
functions must merge, only to create a configuration nightmare three people later
had to untangle.

These slogans are not tools for thinking. They are tools for stopping thought.

"Premature optimization is the root of all evil" is the most dangerous phrase in
software. Donald Knuth wrote it in his 1974 paper "Structured Programming with go
to Statements" and immediately added a caveat: "Yet we should not pass up our
opportunities in that critical 3%." The caveat never made it into the slogan.
The phrase has survived fifty years because it sounds like wisdom, not because it
is useful. "Premature" could mean anything, so it means nothing. People deploy it
as if it means "never optimize." Performance is structural. If you wait for a
production outage, you waited too long.

"Use the right tool for the job" sounds responsible. In practice, it is the most
polite way to say "I already decided." People announce the stack, then retrofit
the justification. Do not announce the right tool until you have studied the job.

"Don't Repeat Yourself" was formulated by Andy Hunt and Dave Thomas in their 1999
book The Pragmatic Programmer as a principle about knowledge duplication, not
code duplication. That nuance was lost. Teams enforce DRY as code style,
producing premature abstractions nobody reuses. The irony: extreme deduplication
creates more duplication, because rewriting the small function is easier than
using the over-abstracted version. As a personal practice, DRY is healthy. As a
weapon in code review, it is destructive. Sandi Metz captured it: prefer
duplication over the wrong abstraction.

"Best practices" without evidence is not a reason. It is a shortcut. Software
best practices are rarely measured. They are ideas from a book or talk, spread
unchecked. The React ecosystem cycled through class components, higher-order
components, render props, hooks, and now server components. Each era's "best
practices" became the next era's anti-patterns. If a rule matters, encode it in a
linter. If it cannot be automated, it needs a rationale deeper than four words.

"Make it work, make it right, make it fast" assumes development happens in clean
phases. It does not. The danger: once something "works," someone starts using it,
and the API is locked. Fred Brooks called this the pilot system, the version you
build to throw away. If you are prototyping, say so.

"Programmer time is worth more than CPU time" is at least honest. It admits you
are trading performance for ergonomics. The problem: it extends forever. Nothing
says "we saved enough time, now optimize for users." This philosophy survives
where competition is low. When users can leave, slow loses to fast.

"Never do a full rewrite" is decent advice most of the time. Rewrites lose years
of accumulated bug fixes and production tuning. Brooks also documented the
second-system effect: teams over-engineer rewrites chasing the "right" way.
Rarely is better than never. Unless you are sneaking a new language into the
stack. A targeted rewrite of one isolated service is a time-tested way to do it.

"You aren't going to need it" came from Extreme Programming in the late 1990s,
coined by Kent Beck and Ron Jeffries. Paired with refactoring, it prevents
over-engineering. Used alone, it shuts down architectural discussion.

"Real programmers don't make that mistake" and "you just need to be disciplined"
are not engineering statements. They are personal criticisms: gatekeeping and
blame. The engineering response is to make mistakes harder to repeat, not tell
someone to try harder.

"It depends" is genuinely true in most contexts. The problem is when it ends a
conversation instead of starting one. "It depends, here are the factors" is
mentoring. "It depends" followed by silence is abandonment. I learned the hard
way. That junior probably still remembers.

"Fast, cheap, good: pick any two" predates software engineering. Brooks's Law
established that adding developers to a late project makes it later. Money does
not reliably buy speed in software.

These phrases are not false. Most contain truth. The problem is that they are
conversation-stoppers, deployed to avoid analyzing the problem in front of you.

AI coding assistants make this dynamic visible. GitHub Copilot and Cursor repeat
code aggressively. They do not plan for performance or know when an abstraction
is premature. Counterintuitively, this helps. A messy version first, then
refactoring, beats premature abstractions. But AI will not tell you when to
refactor. That takes human instinct, the very thing these phrases short-circuit.

AI tools are extraordinary accelerators. They need a thinking engineer who knows
when to let the machine run and when to ask if a cliche is doing the thinking.

The next time you reach for one of these slogans, pause. Ask if you are helping
or just killing a needed conversation. If you cannot defend it without the
cliche, you do not have a position. You have a habit. Habits break.