Personal website of Matthias Endler, a Software Engineer interested in low-level programming and Backend development. Rust, Go

Matthias Endler

The DRY (Don't Repeat Yourself) principle is often misapplied in software development. Copying code can actually be beneficial for maintaining momentum, discovering the right abstractions naturally, and avoiding premature optimization. Wrong abstractions are harder to remove than duplicated code and create mental overhead through multiple layers of indirection. The key is separating writing mode from refactoring mode, allowing duplication initially, and cleaning up once you understand the problem better. Sometimes similar-looking code serves different purposes and should remain separate to preserve context and enable independent evolution.

Repeat Yourself

It’s Hard To Get Rid Of Wrong Abstractions

There is balance to be found between copying and refactoring into a function or object for sure.
When the change is so small I think a refactor is preferred.
Also, if you develop a lot in the creation phase, the refactor phase can only be successful if the dev knows where all the similar code is. The author has advantage over a team member that didn’t write much of the code and has to read the whole thing and remember where the similar pieces are.

Honestly, this article gets DRY completely backwards. The DRY principle isn’t about stamping out every bit of duplicate syntax or boilerplate—it’s about avoiding duplication of meaning and intent across your codebase. Copy‑pasting similar loops or helper functions may help you &quot;keep the momentum,” but it does nothing to prevent the real danger: semantic divergence. When two snippets do the same thing in two places, you need a single, authoritative abstraction so that bug fixes, feature tweaks, and business‐rule changes happen in one place—guaranteeing consistency and avoiding hidden drift.
What the author describes—copying code today and refactoring later—is simply a workflow hack, not a software‐design principle. DRY is about maintaining a single source of truth for each concept, domain rule, or algorithm, not about eliminating all street‐level repetition. Premature or misguided abstractions can indeed be painful, but that just means you need to refine your abstractions, not abandon them. Conflating &quot;don’t repeat code” with &quot;don’t repeat intent” turns DRY into a hollow slogan, and that’s exactly where this article goes off the rails.

I like this take. We should strive for balance.
I hate too many small functions that makes you jump all over the place. It’s harder to read and keep full context in mind.

I like to use Martin Fowler’s Rule Of Three.
Basically when I have copied the code three times it’s a sign that maybe it should be an abstraction.

As my dad always says, excess of anything is bad.