A bit on the sarcastic side but there's definitely some truth to it. This definitely goes against the YAGNI principle.

Very good piece about honesty. It's definitely a core principle to have good communication at work. That being said it covers also all the nuances of difficult situations and how to deal with them.

I definitely agree with this. Managing complexity is our trade.

Discovering Kaketsugi, this is a very impressive craft. True labor of love. This is incredible work, feels almost magical. So much patience and attention to details. The amount of analysis which went into it is amazing too.

This article is spot on in my opinion. This resonates so much with my own experience and ethos... I guess I could have written that if my prose was any good.

Bunch of good advice. In a way it boils down to: name things properly and use static analysis tools extensively. Still, couple of nice operational guidelines which work in most languages.

Very good reminder that as an industry we're quick to blame external factors for our own failures. Of course we can be given a bad hand, but sometimes we'd have failed with a good hand as well.

A good reminder that there is not a one size fits all solution in the tech world. Also be skeptical of the silver bullets that "obviously" everyone should use. Project context matters above all.

Interesting musing on the skills required, why it's actually hard to apply them... clearly it's because you never find a real place to learn them so that ends up being on the job.

Good reminder that the words we use matter. Fuzzy terms like "clean" indeed hide various dimensions to look at the code and the tradeoffs we make.

Or why I'm actually glad I'm not certified even though I could be. This is a good way to stay balanced about all this. At least I'm trying to do my part trying to help people also on the technical areas which are mostly ignored by the "Scrum Industrial Complex" (as Ron Jeffries puts it). Clearly the scrum organizations are not interested in taking up that mantle so it falls onto us.

Interesting thinking about going beyond what's strictly needed for a task.

Very good advises emphasizing empathy and holistic view of products.

This is an excellent list, I admit I agree with most of it. Couple of those realizations are in fact a deep part of what I do.

I still think there are indeed options that work better than others. They are then best practices... BUT they are very much contextual. Due to that complexity, the "personal preference" labelled as "best practice" is indeed pervasive in our industry.

This sounds like a good approach for optimizing on software durability. Obviously this means you loose other things. This is a trade-off.

Obviously I strongly agree with this. Participating in code reviews of free software components is a great way to improve. This applies to being a reviewer, submitting code and skimming other reviews.

Interesting use of mob/ensemble programming to tackle technical debt on projects.

This is actually a good list. Clearly doesn't try to invalidate YAGNI at all, focuses more on this infrastructure things you need on most projects anyway either for debug purpose or because they allow you to change the system easily later which in fact... supports YAGNI.

Interesting coaching approach for teams. It's indeed hard to get teams to stick to some of the difficult development practices... By mixing several approaches, this looks like she's onto something here.