Comment by rockbruno
5 years ago
One mistake I think people like the author make is treating these books as some sort of bible that you must follow to the letter. People who evangelised TDD were the worst offenders of this. "You HAVE to do it like this, it's what the book says!"
You're not supposed to take it literally for every project, these are concepts that you need to adapt to your needs. In that sense I think the book still holds up.
For me this maps so clearly to the Dreyfus model of skill acquisition. Novices need strict rules to guide their behavior. Experts are able to use intuition they have developed. When something new comes along, everyone seems like a novice for a little while.
The Dreyfus model identifies 5 skill levels:
Novice
Wants to achieve a goal, and not particularly interested in learning. Requires context free rules to follow. When something unexpected happens will get stuck.
Advanced Beginner
Beginning to break away from fixed rules. Can accomplish tasks on own, but still has difficulty troubleshooting. Wants information fast.
Competent
Developed a conceptual model of task environment. Able to troubleshoot. Beginning to solve novel problems. Seeks out and solve problems. Shows initiative and resourcefulness. May still have trouble determining which details to focus on when solving a problem.
Proficient
Needs the big picture. Able to reflect on approach in order to perform better next time. Learns from experience of others. Applies maxims and patterns.
Expert
Primary source of knowledge and information in a field. Constantly look for better ways of doing things. Write books and articles and does the lecture circuit. Work from intuition. Knows the difference between irrelevant and important details.
> Primary source of knowledge and information in a field. Constantly look for better ways of doing things. Write books and articles and does the lecture circuit.
Meh. I'm probably being picky, but it doesn't surprise me that a Thought Leader would put themselves and what they do as Thought Leader in the Expert category. I see them more as running along a parallel track. They write books and run consulting companies and speak at conferences and create a brand, and then there are those of us who get good at writing code because we do it every day, year after year. Kind of exactly the difference between sports commentators and athletes.
I don’t think that’s picky at all. GP’s characterization appears to come from a book by Andy Hunt[1]. The two creators (brothers, so both are Dreyfus) of the model don’t say anything of the sort[2].
[1]: https://moleseyhill.com/2009-08-27-dreyfus-model.html
[2]: https://www.bumc.bu.edu/facdev-medicine/files/2012/03/Dreyfu...
The problem is that the book presents things that are at best 60/40 issues as hard rules, which leads novices++ follow them to the detriment of everything else.
Uncle Bob himself acts like it is a bible, so if you buy into the rest of his crap then you'll likely buy into that too.
If treated as guidelines you are correct Clean Code is only eh instead of garbage. But taken in the full context of how it is presented/intended to be taken by the author it is damaging to the industry.
I've read his blog and watched his videos. While his attitude comes off as evangelical, his actual advice is very often "Do it when it makes sense", "There are exceptions - use engineering judgment", etc.
In no way is he treating his book as a bible.
Yup. I see the book as guide to a general goal, not a specific objective that can be defined. To actually reach that goal is sometimes completely impossible and in many other cases it introduces too much complexity.
However, in most cases heading towards that goal is a beneficial thing--you just have to recognize when you're getting too close and bogging down in complying with every detail.
I still consider it the best programming book I've ever read.
But that's what some people are doing - they take this book as the programming bible.
I understand that the people that follow Clean Code religiously are annoying, but the author seems to be doing the same thing in reverse: because some advice is nuanced or doesn't apply all the time then we should stop recommending the book and forget it altogether.
Its not just that it doesn't always apply. Its that the absracted rules are not useful as stand alone guides to developing code, although they are presented as such. Its the entire purpose of the book isn't it? The argument against this book isn't that books about code style and rules are bad. Its that this one is bad. And its often recommended as core reading material to new developers (several examples of that in this thread). I've read several code style / guide books over the last decade. This is one of the few I put down fairly early on because it just didn't seem very good.
Sure, but it doesn't mean the book itself is bad. It's that beginners should be aware that what's "right" differs from project to project.
The whole point of "You HAVE to do it like this, it's what the book says!" is to sell more books or consulting.
I agree: Clean Coders and TDDers are cut from the same cloth.
Agreed. It’s one of the best books on programming there is. Like any book, probably 20% I don’t agree with. But 80% of it is gold.