I haven’t read it in a while but I remember finding it very helpful. I think Martin is a guy who had a good idea and wrote a good book, and then everyone told him he was smart and right, and I think if that happens enough a person will start to believe it. Happens to a lot of people who “achieve success”, whether or not success is merited. Then he kept on saying things he thought and assumed he was smart and right, and some people kept listening because they liked Clean Code, and agreeing because so many other people said he was smart and right, and it snowballed.
I think once you hit a certain level of intellectual celebrity you can sustain your own momentum without needing to understand or respond to criticism, and that’s how people who become famous, like Bob Martin, can turn out the way they do. It happens gradually, and then one day you look at the guy and think “What happened? Was he always like this?” and the answer is yes and no: yes they always said what they think, and no, they weren’t always trapped at the bottom of their own opinion gravity well, slowly becoming a caricature of themselves because their thoughts are no longer guided by the thoughts of their peers.
I read the book after asking some junior engineers why they kept insisting on breaking straightforward tasks that could be a single pure function into a web of stateful method calls and learned they were being recommended it by another senior dev.
That book is one of the major contributors to the object oriented enterprise Java from the 90s that everyone universally loathes.
Oh yeah, the “functions should be short” thing. I think it’s a truism in all fields that novices have to learn a rule before they learn how to recognize the nuances of the rule, and even the “does one thing” guide is hard to implement if you’re in a strict rule-following culture, as many coding shops are, especially for juniors.
It is a big problem especially in enterprise code, where a failure to rule-follow can have severe consequences, and I think the way Martin addresses the problem of function length in Clean Code could stand to be improved upon. However, I think the nature of technical argument is to identify a problem (functions that bloat over time because people keep adding bits to it) and propose a solution (functions over X lines get scrutiny, functions with names like doXandY() get scrutiny, etc), and then the next step, as Ousterhout does in that interview, is to challenge and bring nuance to those proposals in the form of new solutions. The problem with Clean Code is not that the text is imperfect, but that the text was canonized as some kind of Coder’s Bible for a long time, and that prevented a lot of people from seeing or ingesting the criticism of those imperfections, so the imperfections become conventions with inertia that have to be uprooted painstakingly.
Could that interview have happened a decade earlier? Yeah, I think it would have been helpful. Did such an interview happen earlier? I don’t know; my impression is that Martin did little to encourage criticism of his work, and I think that is a professional failing, but I’m also not a close Bob Martin watcher and if he had tried, genuinely tried, I’m not sure I would have seen it. I think wildly successful books often take on a life of their own that authors only partially control, and I have a hard time faulting Martin exclusively for every failure of nuance that was magnified alongside the beneficial parts of the book. I think a lot of Martin’s recommendations about how to analyze code for readability did more good than harm if for no other reason that they normalized discussions about how to evaluate the readability and maintainability of code and why it’s important instead of just focusing on whether or not the code “works correctly” in the moment. I still teach people to monitor their “WTFs per minute” as a heuristic for code quality; I find it very helpful for junior devs to identify both bad code and their own misunderstandings. I think critically analyzing names is excellent advice for all coders. I’m flipping through my own copy and the first thing I underlined back when was “Professionals use their powers for good and write code that others can understand.” I think that’s very good advice for new coders.
Thanks for the link, by the way. I had never seen that before. I haven’t read the whole thing yet but it’s on the list. And I’m reading back through Clean Code for the first time in a long time.
Oh, yeah maybe so; I don’t remember them that well. If I give it enough time perhaps I’ll scrutinize the code examples more closely this time. I generally skim or skip code examples in non-executable media like books; they’re usually so contrived or divorced from their original context that they are no longer useful examples, especially in a domain as context-dependent as large-scale application development. Clean Code was no exception, despite the dire warning about skipping them at the top.
Flipping back through, it looks like I added a few annotations on some of them so I guess I did eventually read them, but I don’t remember them being nearly as essential as he made them out. It was more like, “Remember how we said doing X made code better? Well here’s a snippet before we did X, and here’s what it looks like after X! See how it’s better?” Which, fine, I believe you when you say that that made the code more usable for you and your team. I don’t know how useful it is to generalize decision making about X from a code example vs. just having a general guideline about X and leaving the implementation of that guideline to the implementer i.e. me. I prefer the latter; I think the former leads to the kind of hyper-specific rule following that makes people over-decompose, or put interfaces on top of every single class even if it does nothing but add yet another do-nothing file to the codebase… I digress.
I think I agree, kinda. I’m not sure what I’d define as “irresponsible code” in this context, but I think in general the practice of adding specific examples to highly variable and context-dependent decision making is hard to do, and I think Clean Code might have been better without them.
He wrote a good book decades ago and has slowly rotted his brain since.
The funny thing is that it wasn’t even a good book.
I haven’t read it in a while but I remember finding it very helpful. I think Martin is a guy who had a good idea and wrote a good book, and then everyone told him he was smart and right, and I think if that happens enough a person will start to believe it. Happens to a lot of people who “achieve success”, whether or not success is merited. Then he kept on saying things he thought and assumed he was smart and right, and some people kept listening because they liked Clean Code, and agreeing because so many other people said he was smart and right, and it snowballed.
I think once you hit a certain level of intellectual celebrity you can sustain your own momentum without needing to understand or respond to criticism, and that’s how people who become famous, like Bob Martin, can turn out the way they do. It happens gradually, and then one day you look at the guy and think “What happened? Was he always like this?” and the answer is yes and no: yes they always said what they think, and no, they weren’t always trapped at the bottom of their own opinion gravity well, slowly becoming a caricature of themselves because their thoughts are no longer guided by the thoughts of their peers.
I read the book after asking some junior engineers why they kept insisting on breaking straightforward tasks that could be a single pure function into a web of stateful method calls and learned they were being recommended it by another senior dev.
That book is one of the major contributors to the object oriented enterprise Java from the 90s that everyone universally loathes.
I personally think this discussion is probably the greatest thing he had contributed to software engineering, and not because it puts him in a positive light. https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md
Oh yeah that link does seem interesting. I’ll check it out unless my executive dysfunction gets in the way.
Pure function, is that a functional programming lingo
Pure function = no side effects, no internal state. If you run a pure function twice with the same input, it will give the same output.
Example of pure function
Example of inpure function
let c; (a, b) => { c++; return a+b; }Oh yeah, the “functions should be short” thing. I think it’s a truism in all fields that novices have to learn a rule before they learn how to recognize the nuances of the rule, and even the “does one thing” guide is hard to implement if you’re in a strict rule-following culture, as many coding shops are, especially for juniors.
It is a big problem especially in enterprise code, where a failure to rule-follow can have severe consequences, and I think the way Martin addresses the problem of function length in Clean Code could stand to be improved upon. However, I think the nature of technical argument is to identify a problem (functions that bloat over time because people keep adding bits to it) and propose a solution (functions over X lines get scrutiny, functions with names like
doXandY()get scrutiny, etc), and then the next step, as Ousterhout does in that interview, is to challenge and bring nuance to those proposals in the form of new solutions. The problem with Clean Code is not that the text is imperfect, but that the text was canonized as some kind of Coder’s Bible for a long time, and that prevented a lot of people from seeing or ingesting the criticism of those imperfections, so the imperfections become conventions with inertia that have to be uprooted painstakingly.Could that interview have happened a decade earlier? Yeah, I think it would have been helpful. Did such an interview happen earlier? I don’t know; my impression is that Martin did little to encourage criticism of his work, and I think that is a professional failing, but I’m also not a close Bob Martin watcher and if he had tried, genuinely tried, I’m not sure I would have seen it. I think wildly successful books often take on a life of their own that authors only partially control, and I have a hard time faulting Martin exclusively for every failure of nuance that was magnified alongside the beneficial parts of the book. I think a lot of Martin’s recommendations about how to analyze code for readability did more good than harm if for no other reason that they normalized discussions about how to evaluate the readability and maintainability of code and why it’s important instead of just focusing on whether or not the code “works correctly” in the moment. I still teach people to monitor their “WTFs per minute” as a heuristic for code quality; I find it very helpful for junior devs to identify both bad code and their own misunderstandings. I think critically analyzing names is excellent advice for all coders. I’m flipping through my own copy and the first thing I underlined back when was “Professionals use their powers for good and write code that others can understand.” I think that’s very good advice for new coders.
Thanks for the link, by the way. I had never seen that before. I haven’t read the whole thing yet but it’s on the list. And I’m reading back through Clean Code for the first time in a long time.
I could maybe give him some leeway if the examples in the book itself showed responsible code, but they simply do not
Oh, yeah maybe so; I don’t remember them that well. If I give it enough time perhaps I’ll scrutinize the code examples more closely this time. I generally skim or skip code examples in non-executable media like books; they’re usually so contrived or divorced from their original context that they are no longer useful examples, especially in a domain as context-dependent as large-scale application development. Clean Code was no exception, despite the dire warning about skipping them at the top.
Flipping back through, it looks like I added a few annotations on some of them so I guess I did eventually read them, but I don’t remember them being nearly as essential as he made them out. It was more like, “Remember how we said doing X made code better? Well here’s a snippet before we did X, and here’s what it looks like after X! See how it’s better?” Which, fine, I believe you when you say that that made the code more usable for you and your team. I don’t know how useful it is to generalize decision making about X from a code example vs. just having a general guideline about X and leaving the implementation of that guideline to the implementer i.e. me. I prefer the latter; I think the former leads to the kind of hyper-specific rule following that makes people over-decompose, or put interfaces on top of every single class even if it does nothing but add yet another do-nothing file to the codebase… I digress.
I think I agree, kinda. I’m not sure what I’d define as “irresponsible code” in this context, but I think in general the practice of adding specific examples to highly variable and context-dependent decision making is hard to do, and I think Clean Code might have been better without them.