Intentional Code - Minimalism in a World of Dogmatic Design - David Whitney - Copenhagen DevFest 

Search for an article entitled "It's probably time to stop recommending Clean Code" for more detail, but I'll try to summarize what I've seen. It promotes a style of programming that makes code testable, but also incomprehensible. The speaker talks about cognitive load. In the book itself, a simple function that could be written in 20 lines is spread out over dozens of tiny 3 line functions and sometimes multiple classes, with all the ensuing boilerplate that a programmer reading the code then has to wade through. The style of extreme decoupling of everything tends to lead to low-performance on modern hardware, as well, so people in video games and similar industries tend to treat it with a lot of skepticism. Others have also pointed out that it is ostensibly a book for people newish to software design. Now, people newish to software design tend to interpret any rules they're given dogmatically. Clean Code advocates tend to say "well you shouldn't be dogmatic about it, it's just supposed to be advice for you to think about and you should think critically." Well, newbies kind of can't think critically yet because they lack experience, so that would seem to suggest that the book is for experts, but actual experts also don't really need the book, because they're already experts with pre-existing opinions on what good design is that has been won through actual experience in whatever field they actually work in. So, who's the book really for? (Some believe it's really making RCM money so he doesn't actually have to write software for a living, but of course nobody can really prove that)

Clean Code promotes having functions that are *too* small, that have no real reason to exist as separate entities except to satisfy the "no function longer than 7 lines" rules. Also, the SOLID principles are mostly too vague to be directly applicable to code, despite being presented as such, and they are so widely misunderstood that people can argue for hours over whether putting particular thing in a particular class is (for example) a single responsibility principle violation. Maybe it was helpful in getting some conversations going, but enough devs treat it as this kind of magical scheme that lets you have good code without thinking about it very hard as long as you follow the rules that some of us feel it hasn't been a net-positive for the industry.

@@babgab it's been awhile now that I dont touch the book, but I dont remember this 7 lines rules. But I agree with some of your considerations. Not all.

​@@ThugLifeModafocah He doesn't say "7 lines" directly, so I was misremembering. It's actually kind of worse - he shares a story about going to visit Kent Beck and seeing that all of Beck's functions were 2-4 lines long! And then he shares a refactoring he does of some perfectly understandable code into a horrible incomprehensible wall of text where every function is like 2-4 lines. Pull out your copy and go and read listings 3-1 (original, about 50ish lines) and 3-7 (three pages! THREE!). Compare them. I will tell you up front now, that if you tell me that the sprawling boilerplate vomit that is 3-7 is easier for you to understand, then I will not believe you and if you insist, then I can only assume your eyes do not work the same way mine do and your brain doesn't like nice linear stories as mine does. Instead I can only assume it likes to read code by repeatedly pressing "go to definition" and building a ton of mental context, absolutely ripe for dropping at the first interruption by your coworkers. We have practicing software developers reading this crap and gaslighting themselves into believing that it is the sole right way to do things and that everyone must follow these rules...

@@babgab it is easier to understand because you are not talking in "code" anymore, you are making intentions explicit. Intentions matter most, to us human, than plain algorithm. You write: function processSomething() { goDoX(); goDoY(); const z = goGetZ(); goDoSomethingWith(z); } This is way better than putting all the logic of each method inside processSomething and have lots of variables and flows to wrap your head around it. If you need to fix something with z, probably you can go directly into do something with z to see why it is weird... 6 months after you writing the code you get back and then you need to learn it all over again, because you forgot why you did a logic in some particular way and not the other. I prefer reveal intention over implementation detail. There's an awesome article from Martin Fowler about it (martinfowler.com/bliki/FunctionLength.html), and I agree 100% with him because I was a victim of myself from 6 months ago too many times to keep letting him harm myself today.

​@@vilelivewhat pointers and register manipulations? It's just electric circuits

@@pavelhamanovich4951what electric circuits? It's all just inscrutable (sub)atomic particles.

@@NickFields4 what particles? it's all ratiocentrism and the musica universalis

There's just 3 or 4 words missing from your comment that render it almost totally meaningless.

And a new wardrobe.

Nah, that look has intentionality. I’m here for it.