A few days ago, I published the article Clean Code Is a Lie which I have edited a lot since then.
While most of the feedback was positive, it also triggered strong reactions, especially from people who felt I had attacked principles they consider foundational.
After sitting with that feedback for a bit, I think much of the pushback was justified.
I still believe that software engineering is full of tradeoffs, and that readability is only one constraint among many. But I made that point in a way that was too broad, too provocative, and not concrete enough.
1. A provocative title must be earned
A title like “Clean Code Is a Lie” will immediately rub some people the wrong way. If they already perceive the article negatively before reading the first line, I should expect them to skim it in search of arguments instead of reading it carefully.
That means a title like that needs an article that delivers on that promise and is clear, concrete, and hard to misunderstand.
Mine did not earn that headline.
2. I did not explain strong claims
In the original post, I said things like DRY can lead to wrong abstractions, reusable code can be harder to change, and readability is only one constraint among many. While these may be true, they still require the reader to do some work to understand them.
But if I make strong claims like this, I should not expect the reader to build the examples for me in their own heads.
If I say that DRY can lead to wrong abstractions, I should at least explain it. Two flows look similar, so you merge them into one function. Later they start to differ, and now your function contains a spaghetti of ifs. At that point, the functionality probably should have stayed in two separate functions to begin with, even if that duplicated some code.
Another thing I said was:
“Readability is not the main goal of software engineering. It is a tradeoff.”
This can easily come off as “readability is overrated” or “Clean Code is useless,” even though that was not what I meant. The word “tradeoff” gave the impression that readability matters less than I actually believe it does.
3. Harsh criticism can still contain useful feedback
Many of the responses were unnecessarily harsh. Still, that did not automatically make them useless.
Some people reacted emotionally at first, but once I responded with friendliness and humility, the conversation became constructive, and the criticism became more specific.
Other responses contained no real argument at all, just insults. I do not think there is much value in engaging with those.
The important lesson for me is that I should not judge criticism only by its tone. Some badly delivered feedback still points to a real weakness.
4. I got warned before posting and ignored it
Before publishing, I usually ask AI for critical feedback. In this case, it warned me that the article would likely get a bad reaction.
That was a good warning.
But interestingly, I ignored it. I think the reason is that I liked the provocative framing just a little too much.
That is the most useful lesson for me in all of this: if I feel especially attached to a provocative framing, that is exactly when I should slow down.
Conclusion
When you challenge a widely respected principle, some readers will interpret your weakest phrasing as your actual position unless you remove ambiguity proactively.
If you want to say something sharp, you need to support it properly.
If you think I am still missing something, feel free to tell me in the comments on daily.dev or LinkedIn.