1. 29
  1. 19

    Not surprised. I read Clean Code a year back and Martin’s style there was to advocate an extremely specific, almost-obsessive style of coding without deeply evaluating the why or talking about context. The impression was that it was the Right Way To Code, and any deviation from that was a failing. Stands to reason it’d be the same here.

    For a good book on software architecture, I’d recommend Documenting Software Architectures by Paul Clements et al. While it’s focused on just representing architecture, I found learning how to explain things lead me to being better able to think about architectures.

    1. 5

      Thank you for recommending that book, I am contemplating about ordering it.

      I think as a “junior” dev I read Clean CodER and it actually taught me a few things, so my impression from my first encounter of his writing was very positive. Then I reread it again as I was now in a more senior role and contemplated recommending it to junior devs starting their first job. I was sadly disappointed by the book. I also get the same feeling when I watch RCM talks on youtube, etc. I think its the holier-than-thou attitude that repels me now, as a junior I looked for guidance and I didn’t mind so much, now I find his advice too simplistic and the “Clean X” brand shallow maybe even a bit narcistic.

      His recent ranting blog posts are also disappointing, but I guess not unexpected.

      1. 8

        I read “Coders at Work” and “The Architecture of Open Source Applications” a while back. I wouldn’t describe either as exclusively full of great advice. In fact both often document some really questionable decisions, completely uncritically. However, I think they give a glimpse of people working with very different mindsets from one another because of very different constraints, and projects that make large scale technical decisions for very different reasons.

        1. 3

          For intermediate developers, I can also highly recommend The Pragmatic Programmer. It’s been years since I read it, so I don’t know how well it held up over the years, but I remember when I read it, it had a big influence on how I view programming.

        2. 1

          This is interesting because they talk about the why more than necessary in my expectations

        3. 8

          Hmm. Unhappy with this…. I know many programmers who think they know Good Code when they see it…. but cannot enunciate any principles on which you could use to go forth and write good code.

          But Uncle Bob presents the SOLID principles like hard rules, which rubbed me the wrong way. In fact, I’m pretty sure a system that never violated the SOLID principles would be a giant mess.

          The thing I like about Uncle Bob is he is at least trying. He might not have it down perfect yet… but he is trying.

          I don’t respect criticisms that just says “He is Wrong”. I respect criticisms that say, he is wrong in this concrete case, here is an example, and here is a better principle which resolves this problem.

          The book is silent on improving the architecture of existing systems

          That’s the wrong book for that. You probably want this one https://martinfowler.com/articles/refactoring-2nd-ed.html

          Or “ Working Effectively with Legacy Code” by Michael Feathers

          1. 11

            The appendix tells the story of how Uncle Bob came up with the SOLID principles

            But he didn’t.

            The single responsibility principle has been around for decades. It’s part of the Unix philosophy. ‘Do one thing (and do it well)’. The ‘open-closed principle’ was first stated as such by Bertrand Meyer. The Liskov substitution principle was introduced by Barbara Liskov, hence the name. The ‘interface segregation principle’ is so obvious and trivial that I doubt anyone wrote it down and gave it a name before, filler to make the acronym work. And to describe ‘function arguments’ as some sort of ‘dependency inversion principle’ is truly ludicrous.

            1. 4

              There’s a couple ways to read that sentence, but I think it’s accurate if you don’t read it as saying that Martin invented all of them. I don’t think that’s a fair reading for a few reasons, but the strongest is that Martin wouldn’t have named the LSP after Liskov if he thought he’d created it. Which is unfortunate, because I think he did create that one.

              I got curious about SOLID and especially the LSP a few years ago and researched it, which turned into a talk and short book. Liskov wrote about about types in two solo papers and one with Jeanette Wing that defined a “Subtype Requirement”. The LSP we know was formulated by Martin in a 1995 comp.object post, and it’s about code reuse of classes rather than a computer science model of subtyping. It’s clear he was inspired by Liskov, but she did not create a substitution principle (let alone name it after herself) and Martin’s principle is significantly different.

              Another reading of the sentence is also accurate: Martin collected the principles in a 2000 paper. He ordered them OLDI; the S did not appear. My research didn’t include when that joined or became the acronym we know, but even if someone else added and ordered it, I think it’s safe to credit Martin as primary author because of his many usenet posts, articles, papers, and books popularizing SOLID.

              1. 3

                If I may make a correction (I’m not sure if I understood correctly what you meant by your last sentence), the ‘dependency inversion principle’ which is the D of SOLID is not about injecting dependencies, but rather about the direction of dependencies: high level modules should depend on abstractions and not on low level modules.

              2. 4

                Uncle Bob clearly knows what he’s doing, and he has a lot of good ideas, but IMO he’s not a great advocate for them, and the more real-world experience I get around different codebases the more-strongly I disagree with some of his core tenets, such as “unit tests can and should replace type systems”.

                1. 8

                  unit tests can and should replace type systems

                  I can’t fathom that someone actually believes this

                2. 3

                  Since we’re talking about software design books, I found A Philosophy of Software Design by John Ousterhout to be a good read. It’s a short read at about 170 pages, but it contains important and timeless ideas.


                  1. 1

                    I agree, this is a great book. Very pragmatic, very focused on taste and judgement.

                  2. 1

                    I really liked the book. It’s not a new idea, is basically hexagonal architecture. I also enjoy the ideas of not depending on frameworks and writing tests as if a outer circle.