4 ms·

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 mist

by 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
        I think people get hung up with the small classes/methods and ignore all the rest. One important lesson being that the aesthetics do matter and you have to pay attention to writing maintainable code. These are important lessons for a beginning developer. If you think otherwise, you've never worked on a code base which has 300 line functions with variables named temp, a and myVar. Regarding short functions: yes, having them too short will absolutely cause problems. And you should not use this as an absolute rule. But when writing code it's very useful to keep this in mind in order to keep things simple - when you see your functions doing 3 independent things, maybe it's time to break ivt in 3 sub functions. Edit: I see some criticism concerning too small classes, class variables being used as de facto global variables and shitty inheritance. Fully agree that these are plain bad practices stemming from the OOP craze.
- nyrikki 2y ago
  There tend to be two camps with the Uncle Bob franchise as I see it: Those that fall for the way he sells it, as the 'one true path', or are told to accept it as being so. Those who view it as an opinionated lens, with some sensible defaults, but mostly as one lens to think through. It is probably better to go back to the earlier SOLID idea. If you view the SRP, as trying to segment code so that only one group or person needs to modify it, to avoid cross team coupling, it works well. If you use it as a hard rule and worse, listen to your linter, and mix it in with a literal interpretation of DRY, things go sideways fast. He did try to clarify this later, but long after it had done it's damage. But the reality is how he sells his book as the 'one true path' works. It is the same reason scrum and Safe are popular. People prefer hard rules vs a pile of competing priorities. Clean architecture is just ports and adapters or onion architecture repackaged. Both of which are excellent default approaches, if they work for the actual problem at hand. IMHO it is like James Shore's 'The Art of Agile Development', which is a hard sell compared to the security blanket feel of scrum. Both work if you are the type of person who has a horses for courses mentality, but lots of people hate Agile because their organization bought into the false concreteness of scrum. Most STEM curriculums follow this pattern too, teaching something as a received truth, then adding nuance later. So it isn't just a programming thing. I do sometimes recommend Uncle Bob books to junior people, but always encourage them to learn why the suggestions are made, and for them to explore where they go sideways or are inappropriate. His books do work well for audiobooks while driving IMHO. Even if I know some people will downvote me for saying that. (Sorry if you org enforced these over simplified ideals as governance)
  - michaelcampbell 2y ago
    Which of these leads to 1 sentence per paragraph? I found this incredibly hard to read.

by f1shy 2y ago

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
      I think people get hung up with the small classes/methods and ignore all the rest. One important lesson being that the aesthetics do matter and you have to pay attention to writing maintainable code. These are important lessons for a beginning developer. If you think otherwise, you've never worked on a code base which has 300 line functions with variables named temp, a and myVar. Regarding short functions: yes, having them too short will absolutely cause problems. And you should not use this as an absolute rule. But when writing code it's very useful to keep this in mind in order to keep things simple - when you see your functions doing 3 independent things, maybe it's time to break ivt in 3 sub functions. Edit: I see some criticism concerning too small classes, class variables being used as de facto global variables and shitty inheritance. Fully agree that these are plain bad practices stemming from the OOP craze.
nyrikki 2y ago
There tend to be two camps with the Uncle Bob franchise as I see it: Those that fall for the way he sells it, as the 'one true path', or are told to accept it as being so. Those who view it as an opinionated lens, with some sensible defaults, but mostly as one lens to think through. It is probably better to go back to the earlier SOLID idea. If you view the SRP, as trying to segment code so that only one group or person needs to modify it, to avoid cross team coupling, it works well. If you use it as a hard rule and worse, listen to your linter, and mix it in with a literal interpretation of DRY, things go sideways fast. He did try to clarify this later, but long after it had done it's damage. But the reality is how he sells his book as the 'one true path' works. It is the same reason scrum and Safe are popular. People prefer hard rules vs a pile of competing priorities. Clean architecture is just ports and adapters or onion architecture repackaged. Both of which are excellent default approaches, if they work for the actual problem at hand. IMHO it is like James Shore's 'The Art of Agile Development', which is a hard sell compared to the security blanket feel of scrum. Both work if you are the type of person who has a horses for courses mentality, but lots of people hate Agile because their organization bought into the false concreteness of scrum. Most STEM curriculums follow this pattern too, teaching something as a received truth, then adding nuance later. So it isn't just a programming thing. I do sometimes recommend Uncle Bob books to junior people, but always encourage them to learn why the suggestions are made, and for them to explore where they go sideways or are inappropriate. His books do work well for audiobooks while driving IMHO. Even if I know some people will downvote me for saying that. (Sorry if you org enforced these over simplified ideals as governance)
- michaelcampbell 2y ago
  Which of these leads to 1 sentence per paragraph? I found this incredibly hard to read.