Martin has authored many books and magazine articles. He was the editor-in-chief of C++ Report magazine and served as the first chairman of the Agile Alliance.
So… imagine that someone enters a kitchen, because they want to show you how to make a cup of coffee. As you watch carefully, they flick a switch on the wall. The switch looks like a light switch, but none of the lights in the kitchen turn on or off. Next, they open a cabinet and take down a mug, set it on the worktop, and then tap it twice with a teaspoon. They wait for thirty seconds, and finally they reach behind the refrigerator, where you can’t see, and pull out a different mug, this one full of fresh coffee.
I’ve read parts of Clean Code and Clean Architecture (2 of his main books), and couldn’t get through them. To me, the advice he gives lies between “utter trash” at worse, and “clueless” at best. Everything he says shows a clear lack of practice on his side, it’s well meaning and mostly good-sounding, but it’s either bad advice, or completely subject to interpretation. Take the S from SOLID for example: “single responsibility principle” and guess what it applies to. A function/method? A class (in his OOP sense)? A (micro-)service? A binary? The answer is… yes to all, it depends. Which makes this principle completely useless, because you can always argue your interpretation of the principle is the correct one, over someone who disagrees with you. His advice supposedly goes further than “do one thing and do it well” with the notion of “reason to change” but it’s useless in practice, it always depends on how you define “one thing”. SOLID itself is not trash, but it’s really more a philosophical reflection for every developer to reflect on than real technical guidance.
I’ve said some things about my experiences with him in the past on this site:
Who’s “Uncle Bob”?
I didn’t know either - https://en.wikipedia.org/wiki/Robert_C._Martin
It’s worth reading qntm’s review of Clean Code.
Thank you, this is excellent. I couldn’t help myself from laughing out loud when I got to:
I’ve read parts of Clean Code and Clean Architecture (2 of his main books), and couldn’t get through them. To me, the advice he gives lies between “utter trash” at worse, and “clueless” at best. Everything he says shows a clear lack of practice on his side, it’s well meaning and mostly good-sounding, but it’s either bad advice, or completely subject to interpretation. Take the S from SOLID for example: “single responsibility principle” and guess what it applies to. A function/method? A class (in his OOP sense)? A (micro-)service? A binary? The answer is… yes to all, it depends. Which makes this principle completely useless, because you can always argue your interpretation of the principle is the correct one, over someone who disagrees with you. His advice supposedly goes further than “do one thing and do it well” with the notion of “reason to change” but it’s useless in practice, it always depends on how you define “one thing”. SOLID itself is not trash, but it’s really more a philosophical reflection for every developer to reflect on than real technical guidance.
The primary utility of Clean Code is that if you see it referenced in a job posting you know to back away slowly.
[Comment removed by author]