Beautiful text. She talks with fondness about her grandfather, but there's indeed lessons about craftsmanship here. It's not only about machines, it can't extend into a humanist world view.

Definitely this. One is more painful than the other though. It's a question of paying small price over tine vs paying a big cost later.

Definitely a good advice. We're just better at understanding positive boolean expressions.

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

It's one of the two hardest problems of programming after all. Needs to be thought through.

Since we often still see in the wild code with deep nesting due to edge cases handling, it looks like this advice is still very relevant.

A bit of a rambling, there's something interesting in it though. Splitting small functions early will do more harm than good if they're not reused. Don't assume they automatically make things easier to read.

I always felt uneasy around this "law" as well. It's a good deconstruction of it and proposes proper alternatives. It's all about dependencies really.

Interesting way to look at our profession... I wonder if this is the core reason of why we have a hard time to turn into a proper engineering discipline, is it even possible at all then?

We went from quality to quantity it seems. We also have whole swats of developers who are just consuming content without critical thinking and it's a problem. The conclusion says it all: "Don’t consume. Create. Ask questions. Stay curious."

Interesting take... Is it really practical? Until which size is it viable? What are we loosing by aggregating? Also makes me wonder about alert fatigue... It clearly raises extra questions.

Nice short post listing the main positions (and linking to corresponding articles) on the debate around technical debt. Worth mulling over all those.

We might start in a software career attracted by the "perfection of the machines" (already debatable) but indeed to make anything meaningful we need to interact with other people. I often say it but I'll say it again: it is a team sport.

Indeed, this is the most important skill we need next to coding. Especially in a remote work culture.

Very interesting conversation between Uncle Bob and one of the recent critics of his work regarding performance. I like how he admits some faults in the way he presents things and try to improve for later rather than trying to be right. Some people should learn from that. There's clearly a tension between performance and what is described in Clean Code, it'd be pointless to deny it.

Definitely this. I think this could have turned into a good term until it was used for everything under the sun. It's about maintainability first, not just about what you like or not.

Development is and has to be a team sport indeed.

Good musing about simple code and complexity. We definitely should avoid unwarranted complexity in our code, or at least try to prevent it's spreading.

Having taught quite a bit at the university, having interviewed quite a few junior developers... I have to agree what's proposed here is missing from most curricula. I wish this would be taught more systematically. If not at least students everywhere should know this online course exists.

Good points, this shows quite effectively the problem with blindly following rules without keeping in mind the reasoning behind them.