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.

I've been banging the testing drum for so long I'd have a hard time to not violently agree with that article. I have a couple of beefs with it though, like the sacrificing encapsulation point but other than that...

Interestingly, I'm going through this book right now and indeed I have to agree with most of this article. It didn't age well, it's become a mix of nice advises, things which are kind of obvious nowadays and points which are clearly obsolete. I find that "The Clean Coder" (different topic I know) aged way better. I think I'll give a shot to the proposed alternative book to see...

Very good advice, there's a lot in programming which is really just mundane and boring. That doesn't make it easy but you might end up doing what everyone else tried to avoid.

Or why you should think twice before embarking into a refactoring when it's not directly related to some feature development...

Good exploration of what "engineer" and "engineering" means. Also helps to overcome what software people like us assume is done by the "real engineers" while in fact sometimes they can be as sloppy than us.