I really disagree about damage to our industry over the last 10 or 20 (or 30) years. But I haven't deeply considered such a topic. I have thought a bit about da

I really disagree about damage to our industry over the last 10 or 20 (or 30) years. But I haven't deeply considered such a topic. I have thought a bit about damage to specific areas (e.g. don't get me started on systemd) but damage to such a broad topic as "our industry" I'm inclined to first look for kinds of "original sin" that predates the 90s since "our industry" is older than that. My favorite computer book in the last few years remains The Psychology of Computer Programming which was written in 1971. So many problems brought up in it still bother us to this day, though some have been solved or mitigated or obsoleted. For lack of progress since then in certain areas, is there even really a single person or group left to blame? I'd sooner put ongoing damage to progress or other things as due largely to human nature in things like not knowing history and not learning lessons, the struggles we face as a brand new field of human enterprise (not having hundreds of years to develop guilds and so forth like older enterprises like law or civil engineering have) with incredibly low barriers to entry and dramatically shifting changes in both scale and process in less than an average career's time. On the other hand I understand the broad malaise about agile (in any of its 50+ forms (I like showing/horrifying people https://thedigitalprojectmanager.com/agile-methodologies/ https://thedigitalprojectmanager.com/agile-methodologies/ and there's a fun youtube talk I've misplaced (ed: this one https://www.youtube.com/watch?v=abshdgwqz5Q https://www.youtube.com/watch?v=abshdgwqz5Q))) and desire to point at any of the signatories of the original agile manifesto (Bob among them) or progenitors of Extreme Programming processes as having outsized influence in where we are today. Perhaps Bob has in that way and other ways done more harm than good (I disagree). But if we're dealing with such suppositions, let me bring up another supposition I thought of when I asked myself "if I had to come up with names of industry harmers, who would even make the list that I don't think Bob would land on?" Suppose Bill Gates from the 90s to the 2000s did more harm than good (ultimately I disagree with this one too, though less readily). Whose harm was greater, Bill's or Bob's? If we assume both suppositions are true, I think it's no contest, and Gates' harm was orders of magnitude greater and is still more afflicting us in a myriad of ways despite him not being at the helm of MS for many years while Bob continues consulting, writing books, and making bad tweets. A more interesting contest to consider in this game where to me the relative goods and harms seem within a similar order of magnitude might be Bob vs Stroustrup vs Pike. Well, it's fun to lightly think about such suppositions, but I'm not sure anything useful can come from it. It's probably best left ignored, especially when there's no deep thinking going on. I might have a different perspective if I ran into these groups of younger programmers who treat Bob's word as gospel and make a mess of things I had to clean up. Instead my experience is running into programmers (young and old) who instead don't have any theory or principles or rules of thumb, and inevitably create Big Balls of Mud (http://www.laputan.org/mud/ http://www.laputan.org/mud/). When I do attempt to clean up such balls, at least partially to form a little oasis, Bob's rules are helpful, as are others'. Getting shit under test (specifically unit test -- fast test, i.e. all that is championed by Feathers' Working Effectively with Legacy Code) helps. Breaking dependencies (often to get shit under test) helps. Refactoring big classes with seven arguments in the constructor into a handful of smaller classes with fewer-argument constructors or method calls usually helps (though beware of Ravioli). Thinking about SOLID principles helps. Rewriting without OOP sometimes helps. I look back and see a lot of helpful practices I picked up from somewhere not-Bob, yet many are advocated by Bob. I can't complain too much if he advocates a mixed bag of things I like and things I don't like, compared to if he was almost entirely wrong and there were clear harms. To give an example of "things I don't like", or rather, misinterpretations of over-zealous youngsters, there's this idea that Bob says "Don't write comments." If I actually ran into a dogmatic team requesting I remove all my comments from my commit before it can get past review, I'd pull out Clean Code and have us go through an entire chapter (ch 4) that's all about Comments. Clearly, Bob is a bit more nuanced on this, given there's an entire chapter on his thoughts. The chapter does in fact cover some "whys" as well as "whats", including his primary "why" he's down on comments being that they often lie. Anyway within that chapter I'm sure I can easily find justification for some of my comments, and begin breaking whatever sense of dogma caused dumb things like "no comments" to take hold, with the eventual goal being to not waste time on such trivial things. I don't really think there's all that much "dogmatic push" in Bob's book, even if supposedly there are tons of teams out there interpreting it so. But if they are interpreting it so, then like Bible Thumpers there's often something in the source material itself to move them toward seeing nuance (though nothing in Bob's works to my knowledge has anything like Revelation 22:18-19). There's even an out of context sentence in that chapter by Bob where he wrote: "Some comments are necessary or beneficial." Whaaa, I thought he said no comments ever? (By the way it's not like the idea of "No comments" is clearly attributable to Bob -- you read a lot of old code that far predates him and find a concerning lack of comments. Having a no comment style comes as much from laziness as any principled avoidance of comments -- and at least when it's driven by principle like in Bob's case it's mainly "make the comments redundant to the code by changing the code, then remove them", so the consequences of not many comments are less because at least the code was changed to better support that lack. At least, if it was done to the real principle, and not to some dogmatic perversion like "linter says no comments allowed, because Bob, take them out!") I dislike that the 'philosophy of comments' or style of commenting seemed to Bob to be important enough to deserve a whole chapter. Comments often lie -- so what? That's not a big challenge. To me the whole topic is just not that important -- which is to say that I'm not too miffed by extremes in either direction of over-commenting things or under-commenting things. My goal after getting a dogmatic team on this issue to see nuance would be to then have them not care so much about it in general and spend time elsewhere. I disagree with your characterization that he "targets", like a predator, younger, less experienced, developers. His books and consulting fees are for all. But whatever. I too have issues myself with commonly recommended books like Pragmatic Programmer or GoF. Most recommended books seem to be recommended to younger devs because they're often the only ones asking for any recommendations, too many older devs have given up on the idea of learning and are content with their balls of mud, or in better cases actively seek out books and don't need recommendations as much. But it's hard to sustain a book club at the office (or anywhere). The solution, if Clean Code specifically is a blight on younger devs, is to recommend more books, look for better reading orderings if possible, and stay firm in the assertion that no single book will be sufficient. My preferred "read this first if possible" would be The Practice of Programming; it's not at all useless to read after a few others but it's less helpful the more experienced (in a real N years way, not "same year N times" way) you are. At least it's short. > dogma is not a substitute for understanding I 100% agree. I also think neither Bob nor Linus (I certainly don't) nor the Ghost of Dijkstra nor many other famous programmers would disagree that there are times and excuses for deep nesting in a function, there are times for very long functions, there are times for very deep call chains, there are times goto is needed, there are times to write code instead of the platonic ideal of solving problems with no (new) code, ... and generally speaking when programmers make broad proclamations they're very often in actuality just rules of thumb with room for disagreement, nuance, preconditions, tradeoffs, and outright exceptions. It would be much easier for me to jump on Clean Code if it was actually just a slideshow of such proclamations presented bullet point style, but no, it's a book, and deserves nuanced critique suitable for such a medium.