5 ms·

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of hist

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully unnecessarily complex code in the name of the SOLID principles and others like DRY. Other times completely misunderstanding what the principles stand for and applying them in hand wavy ways. This is a personal stretch, but even the marketing behind the principles is a bit of a red flag for me (Clean Code, SOLID, UNCLE BOB????). To me it sounds like someone made a career out of this. I wish we had a better book to recommend to newcomers.

AlexSW 4y ago
Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.
- DanielVZ 4y ago
  For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.
MrJohz 4y ago
I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller. It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.
- gorm 4y ago
  I was also thinking about this book when I read that article. It's really an excellent book and it's condensed and because it's written by an expert in teaching it's easy to grasp. It's also recommended in this article: "Update, 2020-12-19 After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to recommend it over Clean Code".
  - MrJohz 4y ago
    Haha, I read the article immediately after this comment and saw that comment, I think it wasn't there last time I read it (so presumably before the end of 2020!). I agree that it's probably not as good for complete beginners, but it's really good for anyone with a bit of experience looking to move from "I'm just writing code" to "I'm writing actual software".
Jtsummers 4y ago
I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > 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. Generally dogmatic people don't say, in short, "We could be wrong, we don't think we are, but go see what other people have to say, too.".
- userbinator 4y ago
  The claim is not that the book is dogmatic, but that its worshippers (for lack of a better word) are. The infamous Design Patterns book, despite having a similar "disclaimer", has had a similar effect.
  - deleted 4y ago
    [deleted]
  - Jtsummers 4y ago
    Quoting the person I responded to, who wrote: > the book was inconsistent and dogmatic. How do you square that with: > The claim is not that the book is dogmatic You are claiming they didn't write what they wrote.
- edflsafoiewq 4y ago
  It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.
inimino 4y ago
There are literally hundreds of better books for newcomers. As just one, I would mention Programming Pearls by Jon Bentley. I would say it communicates a much more healthy approach to the craft.
codeape 4y ago
I always recommend "The Pragmatic Programmer" (Hunt, Thomas) and "Code Complete" (McConnell).
flippinburgers 4y ago
Honestly anytime I run into someone spouting something "Uncle Bob" has tried to propagate in our industry while trying to sell books and his "knowledge" I find that it is safe to assume they are probably a perpetual junior level developer.
ravagat 4y ago
Good points, interesting context coming from a history student and now with some experience, I'd like to read more on your thoughts if you have a blog.
- DanielVZ 4y ago
  Thanks! I haven't written much really. I killed my personal site some months ago, and this is the only public blog post I have now, but it's more related to my current side-project and how I got into programming: https://pomasearch.com/blog/why-is-this-site-named-poma-and-who-was-felipe-guaman-poma-de-ayala https://pomasearch.com/blog/why-is-this-site-named-poma-and-...

AlexSW 4y ago

Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.

DanielVZ 4y ago
For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.

MrJohz 4y ago

I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller. It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.

gorm 4y ago
I was also thinking about this book when I read that article. It's really an excellent book and it's condensed and because it's written by an expert in teaching it's easy to grasp. It's also recommended in this article: "Update, 2020-12-19 After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to recommend it over Clean Code".
- MrJohz 4y ago
  Haha, I read the article immediately after this comment and saw that comment, I think it wasn't there last time I read it (so presumably before the end of 2020!). I agree that it's probably not as good for complete beginners, but it's really good for anyone with a bit of experience looking to move from "I'm just writing code" to "I'm writing actual software".

Jtsummers 4y ago

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > 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. Generally dogmatic people don't say, in short, "We could be wrong, we don't think we are, but go see what other people have to say, too.".

userbinator 4y ago
The claim is not that the book is dogmatic, but that its worshippers (for lack of a better word) are. The infamous Design Patterns book, despite having a similar "disclaimer", has had a similar effect.
- deleted 4y ago
  [deleted]
- Jtsummers 4y ago
  Quoting the person I responded to, who wrote: > the book was inconsistent and dogmatic. How do you square that with: > The claim is not that the book is dogmatic You are claiming they didn't write what they wrote.
edflsafoiewq 4y ago
It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.

inimino 4y ago

There are literally hundreds of better books for newcomers. As just one, I would mention Programming Pearls by Jon Bentley. I would say it communicates a much more healthy approach to the craft.

codeape 4y ago

I always recommend "The Pragmatic Programmer" (Hunt, Thomas) and "Code Complete" (McConnell).

flippinburgers 4y ago

Honestly anytime I run into someone spouting something "Uncle Bob" has tried to propagate in our industry while trying to sell books and his "knowledge" I find that it is safe to assume they are probably a perpetual junior level developer.

ravagat 4y ago

Good points, interesting context coming from a history student and now with some experience, I'd like to read more on your thoughts if you have a blog.

DanielVZ 4y ago
Thanks! I haven't written much really. I killed my personal site some months ago, and this is the only public blog post I have now, but it's more related to my current side-project and how I got into programming: https://pomasearch.com/blog/why-is-this-site-named-poma-and-who-was-felipe-guaman-poma-de-ayala https://pomasearch.com/blog/why-is-this-site-named-poma-and-...