Uncle Bob already became part of the problem by some of the stuff he wrote in Clean Code (like using mutable instance fields instead of method parameters). Luckily he isn’t perceived as very relevant anymore.
It's not that I disagree without you about mutable fields vs params, but the industry so disproportionately on the other side of that issue that I'm surprised this objection is raised as often as it is.
Bring it on! Let's have more persistent data structures in standard libraries. Construct a Map by folding new key-vals onto another (possibly) empty Map.
(Rather than creating an empty map and then mutating its instance fields until it's full)
Or ever. If we want to some colleague to tell us what is good code and what isn't, can we please pick someone who at least once demonstratably delivered good software? Bonus points if it was a group effort, and if it was on time.
Common for all these "industry leaders" is that they all write books and give speeches. I'd rather listen to someone who designed successful software such as git or OpenSSH than someone who designed a salary system in the 90s which, it turns out, was scrapped two years later for being a mess. Giving yourself a stage name is not a merit in itself.
There is something to be said for actually understanding the problem first. Did we learn nothing from the TDD nonsense in the 00s?
The famous InfoQ sudoku software design example was chronicled on HN here and should be required reading for anyone who cares about clean code in practice:
> Did we learn nothing from the TDD nonsense in the 00s?
I was never a fan of TDD, but ironically I think it may finally be a good development strategy now with agentic/LLM coding since LLMs do so much better they they have a verifiable goal like passing tests.
Uncle Bob already became part of the problem by some of the stuff he wrote in Clean Code (like using mutable instance fields instead of method parameters). Luckily he isn’t perceived as very relevant anymore.
This is so odd.
It's not that I disagree without you about mutable fields vs params, but the industry so disproportionately on the other side of that issue that I'm surprised this objection is raised as often as it is.
Bring it on! Let's have more persistent data structures in standard libraries. Construct a Map by folding new key-vals onto another (possibly) empty Map.
(Rather than creating an empty map and then mutating its instance fields until it's full)
Or ever. If we want to some colleague to tell us what is good code and what isn't, can we please pick someone who at least once demonstratably delivered good software? Bonus points if it was a group effort, and if it was on time.
Common for all these "industry leaders" is that they all write books and give speeches. I'd rather listen to someone who designed successful software such as git or OpenSSH than someone who designed a salary system in the 90s which, it turns out, was scrapped two years later for being a mess. Giving yourself a stage name is not a merit in itself.
There is something to be said for actually understanding the problem first. Did we learn nothing from the TDD nonsense in the 00s?
The famous InfoQ sudoku software design example was chronicled on HN here and should be required reading for anyone who cares about clean code in practice:
https://news.ycombinator.com/item?id=3033446
> Did we learn nothing from the TDD nonsense in the 00s?
I was never a fan of TDD, but ironically I think it may finally be a good development strategy now with agentic/LLM coding since LLMs do so much better they they have a verifiable goal like passing tests.
3 replies →