Worshiping at the Altar of DRY
There is a particular breed of developer euphoria that comes from looking at a colleague's repetitive code and seeing the "obvious" solution: a clever web of abstractions that eliminates every duplicate line. The code becomes mathematically pure. A thing of beauty. Clean.
I know this feeling well. Years ago, on a graphics editor, a teammate checked in code implementing drag handles for resizing shapes. It worked, but it was verbose. Each shape type had distinct handle logic with its own math, and the code looked like a patchwork of near-identical methods.
My instinct was visceral: this was not clean.
Seeing the duplication, I devised an elegant alternative. I decomposed the existing logic into smaller units, separating the concerns of shape-specific behavior from direction-specific behavior, and composed them back together with a general dispatcher. The result was a codebase half the size with zero apparent redundancy. Surely, if we needed to adjust behavior for a specific direction, we could now do it in exactly one place.
The Morning After
The next day, my manager quietly asked me to revert the change. I was astonished. Had they not seen the old mess? Mine was objectively superior. I reluctantly complied, but I was convinced I was right.
It took years for me to understand that they were, in fact, correct.
Fixing on "clean code" and the elimination of duplication is a formative phase in many engineers' careers. When you are not yet confident in your ability to judge software quality, it is deeply reassuring to cling to something that feels measurable: consistent naming, a tidy folder structure, no repeated blocks. We are told abstraction is a virtue, and after a few years of practice, it becomes a superpower. We see duplication everywhere, and we can't help but abstract it away. Our professional pride gets wrapped up in this identity of writing clean code, and we start measuring our teammates by the same yardstick.
Looking back, my refactoring was a failure on two fundamental levels. First, I never consulted the developer who wrote the code. I unilaterally rewrote their week of work and pushed it to master without a word. Engineering collaboration runs entirely on trust, and trust is eroded—not built—by silent rewrites of someone else's logic, regardless of the technical merit.
Second, my abstraction was not free. By deduplicating, I traded flexibility for tidiness. As the product evolved, we needed increasingly diverse and specialized behaviors for handles across different shapes. These requirements were easy to bolt onto the original, verbose structure. Against my composed dispatcher, however, they would have required an exponential increase in complexity to even express.
Dirty Is Not the Point
Let's be clear that I am not advocating for sloppy code. But it's worth asking yourself: what do you actually mean by "cleanliness"? Which concrete engineering outcomes—the ability to respond to changing requirements, the ease with which humans can collaborate and understand—correspond to your aesthetic feelings of elegance or disgust? I never asked those questions while I was caught up in how the code looked, rather than how it evolved.
Abstraction is a tool of profound utility, but it is not a virtue in itself. It is a means of making sense of high complexity when you cannot yet see how an imminent change will affect the whole. It is a safety net, not a final destination. Do pursue clean code, and rightfully enjoy the moment you discover that a function extraction can dissolve a tangle of boolean logic into something legible. Let that practice be your guide.
But eventually, let it go.
