> At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles.
Absolutely agree with this.
I was a huge fan of clean code, when I first read his books I was fascinated that this man knows what he is talking about, and this is The way how to write code.
Then as my knowledge grew, watched a lot of talks, read more books on the topic and learned new languages that gave me different perspectives, I noticed he borrowed a lot of advices form other experts and put it in a way that was a misinterpretation of the idea of the original author. And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings".
I saw many interviews when the candidate was rejected because of the wrong interpretation of some clean code principles by the hiring manager/lead developer, and the candidate got it right.
> And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings".
A dogmatic following of even the best of ideas often leads to problems (e.g., your interview example). Software engineering is a thinking craft. It's critical to be constantly thinking about the tradeoffs involved in the systems we're building so we can find a better set of tradeoffs. The same goes for the tradeoffs offered by our tools, techniques, approaches, etc. in any given situation. Even the best techniques are the wrong choice in some situations.
I think books, articles, advice from experienced engineers, etc. are best used to set up a set of questions in your head along with default answers. As you gain experience and as our craft evolves, you should be throwing out some of the default answers (or even some of the questions) and replacing them with ones you see elsewhere or ones that your experience has taught you. But they continue to be default answers, not the right answers for every situation.
I can't speak to the "need balls" comment, however he has multiple posts where he discusses types:
> You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.
However I think it's worth pointing out, as a teacher, Uncle Bob seems to not have experience in many languages with high quality type systems and doesn't seem to understand types. He says "I prefer the flexibility of dynamic typing, and the ability to enforce types if, and when, I need such enforcement." As a Clojure person he's probably talking about what Clojure has which does not enforce types at all but really is just a runtime assert system.
The following is vaguely in support of types but it's mostly incoherent. Where is "The Dark Path" he refers to? He seems to have a very narrow view of types, no concept of "correct by construction" with an expressive type system. His go-to example in this piece is that enforcing a function is called with an "int" instead of "double" and then talks about how that probably isn't even necessary for correctness of the program. So, you see, types are a negative there! And, maybe, it depends on what you're writing. Why he didn't choose "int" vs "string" where the incorrectness of calling one with the other should be quite obvious, I do not know.
His assertion that types do not impact the number of unit tests one writes I, also, do not agree with. It's not one or the other, but there are whole classes of unit tests you can avoid writing with types.
Martin was just repackaging the idea of high cohesion from Constantine, who got the idea from Christopher Alexander's doctoral thesis, notes on the synthesis of form.
https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleRepon...
https://en.wikipedia.org/wiki/Separation_of_concerns
https://en.wikipedia.org/wiki/Conway's_law
Because Uncle Bob also gave us SOLID, it also has the confused SRP instead of SoC as the S.
https://en.wikipedia.org/wiki/SOLID