I think this author has some points, but this is attacking the wrong thing.
Clean code is not the source of the problems described. If you see similar code and try to extract a common abstraction without further consideration, congrats, you’re thinking like a junior developer, and that’s not Clean Code’s fault, to pull one example.
The problem is that people recommend clean code to junior developers all the time. Clean Code is full of terrible advice and heuristics over critical thinking throughout, and is usually foisted on burgeoning juniors when they don’t know any better.
In other words, you’re correct that adherents of clean code are thinking like junior developers, because that’s what clean code tells you to do.
That’s not my observation. I could flip it around and accuse the author of defending massive if/else chains because my experience is that anything that needs more than a handful of lines of code is either a complex mapper or a nightmare of failed Boolean algebra.
That doesn’t mean the bad code I’ve seen is OP’s fault. It means there’s a lot of shit programmers and adopting a particular style doesn’t fix it.
Then you’re just wrong. Clean Code directly tells you to make the mistakes the author of the article points out. The absurdity of the examples in the book should be evident enough.
I think this author has some points, but this is attacking the wrong thing.
Clean code is not the source of the problems described. If you see similar code and try to extract a common abstraction without further consideration, congrats, you’re thinking like a junior developer, and that’s not Clean Code’s fault, to pull one example.
The problem is that people recommend clean code to junior developers all the time. Clean Code is full of terrible advice and heuristics over critical thinking throughout, and is usually foisted on burgeoning juniors when they don’t know any better.
In other words, you’re correct that adherents of clean code are thinking like junior developers, because that’s what clean code tells you to do.
That’s not my observation. I could flip it around and accuse the author of defending massive if/else chains because my experience is that anything that needs more than a handful of lines of code is either a complex mapper or a nightmare of failed Boolean algebra.
That doesn’t mean the bad code I’ve seen is OP’s fault. It means there’s a lot of shit programmers and adopting a particular style doesn’t fix it.
Then you’re just wrong. Clean Code directly tells you to make the mistakes the author of the article points out. The absurdity of the examples in the book should be evident enough.