We have become obsessed with abstractions, DRY principles, and "best practices". The result? Codebases that are impossible to change. Here is why I embrace "Write Everything Twice"
I used to be a Clean Code zealot.
I would spend hours refactoring a working function just because it had too many lines. I would create abstract classes for features that didn't exist yet. I religiously followed DRY (Don't Repeat Yourself).
If I saw the same logic twice, I abstracted it immediately.
Ten years later, I realized something painful: My "clean" code was actually the hardest code to maintain.
Here is why the industry obsession with "Clean Code" is a trap, and why you should probably lower your standards.
1. The Wrong Abstraction is Expensive
The cardinal sin of Clean Code is "Premature Abstraction."
You see two functions that look similar. You merge them into one generic function with a few parameters. It looks neat.
Two months later, one use-case needs a slight variation. You add a boolean flag. Then another variation needs an if/else. Then another.
Suddenly, your "clean" generic function is a monstrosity of conditional logic that breaks 5 different parts of the app every time you touch it.
The Fix: Use the WET principle (Write Everything Twice). Copy and paste is not a crime. It decouples your logic. It is better to have duplicate code than the wrong abstraction.
2. Optimization for "Reading" vs. "Changing"
Clean Code books tell us to optimize for readability. Small functions. Descriptive names.
But in a startup or rapid-growth environment, the most important metric is Changeability.
Code that is split into 50 tiny files and abstract interfaces is hard to change. You have to jump between 12 tabs just to understand a single data flow. That is cognitive load.
Sometimes, a 500-line function where you can see everything happening in one scroll is superior to 10 "clean" 50-line functions scattered across the project.
3. "Best Practices" are for Google, Not You
Most "Best Practices" (Microservices, Hexagonal Architecture, intense TDD) were invented by companies with 10,000 engineers to solve communication problems, not engineering problems.
When you apply enterprise constraints to a 3-person team, you aren't ensuring quality. You are ensuring slowness.
4. Code is a Liability
We treat code like an asset. We polish it like a trophy.
But code is a liability. Every line you write is a line that can break, needs testing, and requires reading.
The goal of a Senior Engineer shouldn't be "Beautiful Code." It should be "Minimal Code."
The "Good Enough" Manifesto
I am not saying you should write garbage. But there is a massive difference between "Sloppy" and "Pragmatic."
Sloppy: No variable names, no consistency, bugs everywhere.
Pragmatic: Duplication is okay. Long functions are okay. Hard-coding values is okay until you need them dynamic.
Stop trying to impress the compiler. Stop trying to impress "Uncle Bob."
Write code that is easy to delete. Because the only code that doesn't have bugs is the code you delete.
Agree or disagree? Are we over-engineering our daily work? Let’s fight in the comments.
Top comments (0)