Post #4072225

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.