this post was submitted on 10 Aug 2024
145 points (95.0% liked)
Programming
17354 readers
311 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I feel like it’s wrong to idolize anything in the same way that it’s wrong to throw out many things (there are some clear exceptions usually in the realm of intolerance but that’s unrelated to this). Clean Code, like every other pattern in software development, has some good things and some bad things. As introduction to the uninitiated, it has many good things that can be built on later. But, like Gang of Four, it is not the only pattern we apply in our craft and, like Agile, blind devotion, turning a pattern into a prescription, to Clean Code is going to lead to a lot of shit code.
Cognitive load helps us understand this problem a lot better. As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line? The latter two options increase a junior’s extraneous cognitive load, further reducing the already slim amount of power they can devote to germane cognitive load because their levels of intrinsic are very high by the definition of being a junior.
Put a little bit differently, perfection (alternatively scalable, maintainable, shipped code) comes from learning a lot of flawed things and adapting those patterns to meet the needs. I am going to give my juniors flawed resources to learn from to then pick and choose when I improve those flaws. A junior has to understand the limitations of Clean Code and its failures to really understand why the author is correct here. That’s more cognitive science; we learn best when we are forming new connections with information we already know (eg failing regularly). We learn worse when someone just shows us something and we follow it blindly (having someone solve your problem instead of failing the problem a few times before getting help).
I’m gonna be super hand-wavy with citations here because this a soapbox for me. The Programmer’s Brain by Felienne Hermans does a good job of pulling together lots of relevant work (part 2 IIRC). I was first introduced to cognitive load with Team Topologies and have since gone off reading of bunch of different things in pedagogy and learning theory.
The article goes into that. Clean Code has some good advice. But it also got bad advice.
Problem is, the good advice is basic. Anyone working in the industry will pick most of these up. All the good advice could be summed up in 10 pages or so.
The bad advice is incredibly bad - and in the worst cases even be counter productive. A newbie won’t be able to tell these advice apart. Some professionals might not either. So they adopt these techniques to their code, and slowly their code turns into an unmaintainable mess of spaghetti.
So no, the book shouldn’t be recommended to anybody. It has already done enough harm to the industry.
I see what you’re getting at it, and I agree we shouldn’t increase the load for juniors upfront. But I think the point is mainly there are better resources for juniors to start with than Clean Code. So yeah, the best option is to throw it out completely and let juniors start elsewhere instead, otherwise they are starting with many bad parts they don’t yet realize are bad. That too would increase cognitive load because they would need to unlearn those lessons again.
Exactly. The article is pretty clear with this point. Junior devs aren't the ones we should be giving mixed bags of advice to.
I’m all for it! What’s the resource that solves this problem?
It must be perfect since we can’t ever give mixed bags of advice. There are apparently better resources although I didn’t see one in the article and things like Code Complete and Pragmatic Programmer address a lot of the same things. Hell, we probably shouldn’t talk about The Mythical Man-Month anymore either. Do we also throw out Design Patterns since singletons are arguably bad design these days?
Literally no need for that level of sarcasm.
I took the things defined in the comments responding to mine and extended them. If we can’t share a mixed bag, all of the things I highlighted are out. It would be logically inconsistent to think otherwise starting from your conclusions. Either we have perfect resources or we have, as I called out, to pick and choose our battles. I want to see a perfect resource not ad hominem.
Edit: genuinely surprised to see someone on a CS instance not understand reductio ad absurdum/impossibile (depending on how you feel about Gang of Four)
Telling you that you don't need to be sarcastic is not ad hominem.
Your response was to call my argument sarcasm. That is directed at me rather than what I said. That’s quite literally, not figuratively, the definition of sarcasm.
I wish you the best of luck. You don’t seem to be interested in the comments unless it agrees with you and you have yet to share a perfect resource. Have fun!
You're not owed a response. This is an internet forum, not a debate. If I don't want to engage with someone who is being sarcastic and condescending that's allowed. Especially so when your first reply to me was a straw man argument. I never claimed perfect advice exists. You're acting as if I would look at something 99% good and say it's a "mixed bag" of advice because it isn't 100% good. I don't know how to view that as something other than sarcasm. I don't know how to take saying things like how you're shocked people wouldn't know this as something other than condescension. All you've done is act hostile towards me. And for what, because I mildly disagreed with something you said and refused to take the bait and get in a flame war? Literally even now you close this comment with sarcasm.
Life is too short for this shit. If you wanted a real discussion maybe say "I didn't mean that sarcastically," instead of being condescending.
It's inspired so many crimes against engineering as a whole that it's OK to discourage people from reading it. Not only is it pointless, but it's also actively harmful to the industry as a whole.
When something is mostly garbage and good advice is so sparse in it, there's no need to hold onto it. It's as much of a mixed bag as a turd with a nice ribbon is a mixed bag of prettiness.
Burn it with napalm.
.... Nah, I don't actually mean it should be burnt, that was a joke. The book is a nice reminder that, on top of being a bigot, Robert Martin (not my uncle) should not be hired to write any kind of code in any professional capacity.