What is your modern
Perhaps this book had a greater impact on me when I read it than I believe. However, I already had a lot of habits and patterns in programming by then that I don't think changed a lot after I read it the first time in the early 2010s. Maybe the next thirteen chapters will change my opinion, but at present I'm still inclined to include it in a short list of books I'd suggest to mentees and really don't get the hate it was getting in the other discussion.
That said, I've always been a synthesist. I acquire information and ideas from wherever I can find them, and put them together to form my own concepts and techniques. I would not recommend this as the book on clean coding practices. But it is certainly a book on the topic and has useful material especially for someone with just a few years of experience post college.
Confusion comes from CS which is based on math which is based on determined set of rules and axioms.
But modern software engineering is more art, CS is just one of many tools at your disposal.
So many developers and book authors still don’t get it.
There are no laws or rules that just works — u always have to think for yourself.
=> any book teaching you specific principles or practices would be incomplete and incorrect in some big set of cases.
#2. CC is a great book, as any book written by experienced engineers.
You just have to remember #1 and learn to understand motivation and applicability of each idea in a book.
It's relatively short and doesn't commit the sin of providing code snippets. It only lays down general rules about software development and give generic heuristic for better software design. Nothing specific to code. It has no prescriptive rules on the way you write code, but rather, on which code to write. This makes the recommendations timeless despite the fact the book is fairly old. As someone who was just starting in development at the time, it was a HUGE help and provided insights that I can only agree with now that I'm working in the field. Maybe for someone who has a bit of experience already, it might just elicit shrugs, but I think it's a good introduction on how to think about software design.
Except for what he says about TDD.
- you know what the book praises (and that's good), so it's not useful to you (or your peers) anymore: good variable names, functions should do one thing, hide internal structures, etc., you name it. We all know that and we practice it without effort. To be honest, most engineers with more than 5 or so years of experience know all these "rules" already
- some "juniors" read the book and take it as any other general book about programming: some things are good, some things are bad, other things are "meh". These "juniors" are quite practical people and tend not to get influenced by "tech celebrities" that much. These are good "juniors" (I wouldn't call them juniors, though)
- other "juniors" take the book as if it were their bible. They do everything the book says and don't stop and think by themselves. The usual excuse is: "Uncle Bob, Robert Martin, DHH, etc. they all are top notch tech people, I follow them without doubt". These, imho, are "bad" juniors... and, to be honest, it's not about tech at all, these kind of people are like this in every other aspect of their lives (e.g., politics). So, I don't care much about them because it's difficult for them to change this perspective on life.
To summarize: programming books written by "tech celebrities" can cause as much harm as good. Depends on who's reading the books.
Hahahahahahaahahahaha
I've had to clean up more 3k SLOC functions from 15+ year programmers than < 5 year programmers. And the number of times I've done that has not been just one or two, it's been a few times a year every year of my career. And variable names? Those are the ones still hung up on Hungarian notation.
Nothing about seniority makes people good at this work. Knowledge and good sense are not magically delivered with time. They're delivered with education (mentorship, school, reading, watching), experience, feedback, and introspection.
Regarding this book, I'm only at chapter 4 in my reread, and so far I really don't see the controversy. I will agree the refactoring in Chapter 3 (the one cited in the big discussion yesterday) could be better motivated and discussed. However, it does make sense in the context of the book. It's also worth noting these two paragraphs from early on in the book:
> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.
> Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
The author is literally saying: I could be wrong! I'm going to write is if everything here is The Truth, but it may not be. Go learn from others and make your own way.
Now, many people may miss this, but it should help to address the '"juniors" take the book as if it were their bible' issue. Point it out to them, if they really take it as their bible maybe they'll wise up. If not, they probably would've been dogmatic zealots no matter whose book they read early on.