Good reminder on why mypy is an essential mitigation to use when dealing with Python. This avoids some quite common mistakes.

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.

Now that is indeed an interesting bug. Time can be a fickle friend... arithmetic as well.

This is a good highlight of the differences. It's not "one is best", it is really "pick what is best in your context".

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

Illustration of one of the traps I hate most with Python.

Not 100% convinced by all the points, but definitely a good conversation to have around the pull/merge request model. Might need a minimum threshold to be crossed in term of team maturity though.

Bumped into this. It's indeed nice, full of good advises for handling code reviews.

This is a good summary of why I like my type system to be "tight", strong and statically checked.

Good (and long) exploration of the field, going into the different variants provided by various languages.

Nice extracts with comments about finding joy in your (work) life or not. Two paths really... which one are you on?

Too bad this is stretching a bit too far on the politics side (although it's not unjustified, I think it muddies the initial message in this context).

Nice comprehensive list of the smart pointer types in Rust.

A nice list of interesting nuggets from the functools python module.

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

Very good points about why elegance matters in code. It's definitely something I try to keep in mind in code reviews. One has to be careful not to use too obscure features of the language though. For instance, you're mostly fine in Python where what it considered idiomatic is somewhat well defined, you're much more in trouble in C++ which isn't as cohesive.

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.

Very good rant which explains nicely why rewriting some software from scratch is almost never the right answer.

Second time I bump into this book being mentioned somewhere. This good summary really makes me want to read it. At least it gives a clear overview of complexity and how it's tied to other softer topics. I especially like the distinction between tactical and strategic, it's one I do often. I think I'm particularly willing to read the chapters about comments and TDD... from the summary it seems it's where I'm the most at odd with the ideas in there.

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...