The linter flagged two hundred warnings in the legacy file.
A developer set out to fix them all. The senior developer watched.
After an hour, the senior asked, “Has the code become better?”
“It has become quieter.”
“Are those the same thing?”
Sitting with the Koan
There is something deeply satisfying about a clean linter report. The warnings disappear one by one, the count drops, and eventually the tool goes silent. We feel productive. We feel like we have accomplished something real.
But the senior developer’s question cuts straight to the heart of what we were actually doing.
Quieter and better are not synonyms, even though we often treat them as if they were. A linter measures conformance to rules. Rules are not wisdom. They are the codified opinion of a community at a particular moment in time, about a particular set of concerns, most of which have nothing to do with whether your software does what it needs to do, or whether the person who reads it next year will understand what you were trying to say.
When the developer answers “it has become quieter,” there is real honesty in that reply. It is a more precise answer than “better.” Quieter is measurable. Better requires a definition that neither the tool nor the task ever provided.
This is the trap that linters, formatters, and static analysis tools set for us. They offer a countable, completable thing in a domain where most of what matters is neither countable nor completable. And because the human mind finds great comfort in finishing things, we can spend an hour silencing warnings in a file that nobody reads, that encodes a business rule nobody remembers, in a system that is slowly being replaced. The warnings are gone. The code has not changed in any way that matters.
None of this means linters are wrong or useless. Consistency has genuine value. Catching certain classes of error before runtime is genuinely useful. The point is not that the developer should have ignored the warnings. The point is the question the senior developer asked, and when they asked it.
Before we fix, we might ask: what does fixing mean here? Before we clean, we might ask: what is the mess actually costing us? Before we make something quieter, we might ask: is the noise the problem, or is the noise telling us something we would rather not hear?
Two hundred warnings in a legacy file is not just a style problem. It is a signal. It is the accumulated residue of years of decisions made under pressure, by people who are no longer around to explain themselves, in a context that has probably changed. Silencing the signal is one response. Reading it is another.
The senior developer is not telling the junior not to fix the warnings. They are asking the junior to be present for what they are actually doing, rather than mistaking the feeling of progress for progress itself.
The linter can tell you that your code is quieter. It cannot tell you whether that silence is peace or avoidance.