5 ms·

Why is the book no longer considered good practice? Are there a specific list of bad practices it uses?

sdevonoes 5y ago
I would say: it's not relevant for senior engineers anymore. - 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
- dave_sid 5y ago
  But it must still be relevant to junior engineers? Or is it considered bad practice?
  - sdevonoes 5y ago
    I think it's tricky. In my experience: - 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.
- Jtsummers 5y ago
  > - 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 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.

I would say: it's not relevant for senior engineers anymore. - 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

dave_sid 5y ago
But it must still be relevant to junior engineers? Or is it considered bad practice?
- sdevonoes 5y ago
  I think it's tricky. In my experience: - 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.
Jtsummers 5y ago
> - 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 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.