I'm going to say something that will probably annoy a lot of developers.
Clean code is overrated.
Before you start quoting Clean Code by Robert C. Martin, hear me out.
I've seen developers spend more time trying to make code look clean than trying to understand whether the code itself is well designed.
They extract every repeated line into a function.
They create abstractions for logic that only exists in one place.
They introduce interfaces for implementations that will probably never change.
They split simple operations across multiple files, then call the result "maintainable."
And somehow, the more complicated the codebase becomes, the more proud they are of its architecture.
But here's my question:
If I need to jump across seven files to understand a simple operation that could have been expressed clearly in one place, what exactly have you cleaned up?
The indentation?
The file structure?
Or your own conscience?
I'm not arguing that readable code is unimportant. I'm arguing that readability, simplicity, and maintainability are not automatically the same thing as following every clean-code principle religiously.
Sometimes duplication is better than the wrong abstraction.
Sometimes a longer function is easier to understand than five tiny functions with vague names.
Sometimes the simplest architecture is the one that solves today's problem without pretending you're already operating at Google's scale.
And sometimes, in the pursuit of "perfect" code, developers create complexity that didn't exist before.
Good engineering isn't about making code look impressive to other developers.
It's about making the system understandable, reliable, testable, and easy enough to change when requirements inevitably evolve.
So here's my controversial question:
Have we reached a point where some developers write code to impress other developers instead of writing code to solve problems?
I want to hear from people who disagree.
When does clean code become overengineering, and how do you tell the difference?
Top comments (0)