6 ms·

This short book is (IMHO) one of the best on software design. To me the main point of the book is the importance of well-designed abstractions. The "surface a

This short book is (IMHO) one of the best on software design. To me the main point of the book is the importance of well-designed abstractions. The "surface area" of a well-designed abstraction is small, easy to understand, and helpful as you reason through your code when you use it. The underlying implementation may be deep and non-trivial, but you find that you don't have any need to worry about the underlying internal details. In short: A beautifully designed abstraction is easy to understand and use. It is so trustworthy that you don't feel any need to worry about how it is implemented. Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.

f1shy 2y ago
That book is a almost perfect summary of what is in my head after 30+ years of programming. I recommend it often to new people, as I see they make the same mistakes I did back then. I recommend not loosing time with “Clean X” books, but instead read this book. Also, as noted in other comments, you can only “get it” after some real experience, so it is important to practice an develop a “common sense” of programming.
- karmakurtisaani 2y ago
  I disagree that the "Clean X" books are a waste of time. They lay a nice ground understanding of what to aim for when writing code, in particular when you're early in your career. When I was starting as a professional coder years ago, I had an intuitive sense of what good code was, but I had no idea how much actual thought had been put to it by other people. Reading those books was a good step in seriously starting to think about the subject and look at code differently as a craft ("it's not just me, this code smells!" or "hey that's a neat idea, better keep this in mind"). Definitely would recommend to someone starting out their career. Edit: getting downvoted for a reasonable, justified opinion. Classy.
  - f1shy 2y ago
    I think you are totally right. The clean X books are not a waste of time. I meant that in the sense of “start here, don’t delay this”. I would recommend: read aPoSD, then Clean X series, then again aPoSD ;)
  - pdpi 2y ago
    Don’t know about the rest of the series, but Clean Code isn’t merely a waste of time, it’s worse — it’s actually a net negative, and lies at the root of a number of problems related to incidental complexity.
    - karmakurtisaani 2y ago
      Care to elaborate?
      - whstl 2y ago
        Not GP but: Personally, I find that book's advice is highly subjective and rooted on aesthetics rather than pragmatism or experimentation. It encourages an excessive number of very small methods and very small classes, and brushes off problems that it causes. Not about the book, but: Its influence is malignant. Even Uncle Bob mentioned in a recent interview that he will break the "10 lines per method" rule if need be. But practitioners influenced by the book lack his experience, and are often very strict. I even remember a specific Ruby linter that capped methods at 5 or 6 lines max IIRC. Working in such a fragmented codebase is pure madness. This comment from another user made me remind some of those codebases: https://news.ycombinator.com/item?id=42486032 https://news.ycombinator.com/item?id=42486032 EDIT: After living in the "Clean Code world" for half a decade I can categorically say that it produces code that is not only slow to run (as argued by Casey Muratori [1]), but also slower to understand, due to the jumping around. The amount of coupling between incestuous classes and methods born out of "breaking up the code" makes it incredibly difficult to refactor. [1] https://www.youtube.com/watch?v=tD5NrevFtbU https://www.youtube.com/watch?v=tD5NrevFtbU
        karmakurtisaani 2y ago
begueradj 2y ago
> A beautifully designed abstraction is easy to understand and use. It's like in "Clean Code" where Ward Cunningham said a clean code is a beautiful code. Beautiful design, beautiful code, beautiful abstraction, beautiful class, beautiful function ... But is not that subjective and broad ?
- AnimalMuppet 2y ago
  Yes, it's subjective, but not entirely. After you've done it for a couple of decades, you start to have a sense of taste, of aesthetics. Some things seem beautiful, and others ugly. It's "subjective", but it's also informed by two decades of practice, so it is far from being purely subjective.
- cratermoon 2y ago
  Robert M. Pirsing discusses qualia in his writings. One objection raised by his antagonists is, “quality is just what you like", echoing the idea of broad subjectivity you raise. Yet there is broad agreement on what counts as quality. Among the aspects we agree on is complexity and subjective cognitive load.

f1shy 2y ago

That book is a almost perfect summary of what is in my head after 30+ years of programming. I recommend it often to new people, as I see they make the same mistakes I did back then. I recommend not loosing time with “Clean X” books, but instead read this book. Also, as noted in other comments, you can only “get it” after some real experience, so it is important to practice an develop a “common sense” of programming.

karmakurtisaani 2y ago
I disagree that the "Clean X" books are a waste of time. They lay a nice ground understanding of what to aim for when writing code, in particular when you're early in your career. When I was starting as a professional coder years ago, I had an intuitive sense of what good code was, but I had no idea how much actual thought had been put to it by other people. Reading those books was a good step in seriously starting to think about the subject and look at code differently as a craft ("it's not just me, this code smells!" or "hey that's a neat idea, better keep this in mind"). Definitely would recommend to someone starting out their career. Edit: getting downvoted for a reasonable, justified opinion. Classy.
- f1shy 2y ago
  I think you are totally right. The clean X books are not a waste of time. I meant that in the sense of “start here, don’t delay this”. I would recommend: read aPoSD, then Clean X series, then again aPoSD ;)
- pdpi 2y ago
  Don’t know about the rest of the series, but Clean Code isn’t merely a waste of time, it’s worse — it’s actually a net negative, and lies at the root of a number of problems related to incidental complexity.
  - karmakurtisaani 2y ago
    Care to elaborate?
    - whstl 2y ago
      Not GP but: Personally, I find that book's advice is highly subjective and rooted on aesthetics rather than pragmatism or experimentation. It encourages an excessive number of very small methods and very small classes, and brushes off problems that it causes. Not about the book, but: Its influence is malignant. Even Uncle Bob mentioned in a recent interview that he will break the "10 lines per method" rule if need be. But practitioners influenced by the book lack his experience, and are often very strict. I even remember a specific Ruby linter that capped methods at 5 or 6 lines max IIRC. Working in such a fragmented codebase is pure madness. This comment from another user made me remind some of those codebases: https://news.ycombinator.com/item?id=42486032 https://news.ycombinator.com/item?id=42486032 EDIT: After living in the "Clean Code world" for half a decade I can categorically say that it produces code that is not only slow to run (as argued by Casey Muratori [1]), but also slower to understand, due to the jumping around. The amount of coupling between incestuous classes and methods born out of "breaking up the code" makes it incredibly difficult to refactor. [1] https://www.youtube.com/watch?v=tD5NrevFtbU https://www.youtube.com/watch?v=tD5NrevFtbU
      - karmakurtisaani 2y ago

begueradj 2y ago

> A beautifully designed abstraction is easy to understand and use. It's like in "Clean Code" where Ward Cunningham said a clean code is a beautiful code. Beautiful design, beautiful code, beautiful abstraction, beautiful class, beautiful function ... But is not that subjective and broad ?

AnimalMuppet 2y ago
Yes, it's subjective, but not entirely. After you've done it for a couple of decades, you start to have a sense of taste, of aesthetics. Some things seem beautiful, and others ugly. It's "subjective", but it's also informed by two decades of practice, so it is far from being purely subjective.
cratermoon 2y ago
Robert M. Pirsing discusses qualia in his writings. One objection raised by his antagonists is, “quality is just what you like", echoing the idea of broad subjectivity you raise. Yet there is broad agreement on what counts as quality. Among the aspects we agree on is complexity and subjective cognitive load.