Indeed, the times when we could pretend one was a superset of the other are long gone.

Updating database schema or interfaces between services should take time if you want to limit the downtime. The extra work involved might mean you should accept a little downtime instead. It probably should be on a case by case basis rather than a blanket policy.

Interesting list. Definitely to keep in mind when developing and deploying a web application.

Interesting take. Will it lead to paying more attention to performance in software? Will it be the rise of the specialized CPUs? Time will tell.

A good counterpoint to the "choose boring tech" which I tend to agree with. Sometimes you need to look into unusual tech and it's fine. Just have to do it rarely and responsibly. The context matters.

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.

This trend around critiquing code reviews on the argument of "trust" should be challenged indeed. This is just the wrong way to approach it.

Interesting new tool for easily setting up dev environments. The real added value to previous such tools is it's open source nature and the fact that you can fully control on which infrastructure the environments will be created.

Definitely this. It takes time of course, I don't do it nearly enough... I never regretted it though.

The copyright problem in all this is becoming more and more obvious...

Very early days and still hackish to use but that's definitely big news for the Python ecosystem.

Good explanation of how flame graphs are produced and how to read them. Gives a few tips on what to look for to optimize.

Nice piece, not perfect, good food for thought still. We definitely need more ethics in our craft.

Good primer on Python properties. Opens the door to lower level mechanisms in the language.

Very good interview. She really point out the main issues. Quite a lot of the current debate is poisoned by simplistic extrapolations based on sci-fi. This distracts everyone from the very real and present problems.

Definitely this. This is an interesting talk, most thing shouldn't be shiny. It's not about stagnating of course, but you should think more than twice before adding a new technology to your stack. Mastery is when you know everything that's wrong with a piece of tech, before that keep in mind the amount of unknown unknowns and the cost of exploiting something new.

This nicely goes in depth on the five domains to look at to know where you stand as a manager. Also proposes action to increase the impact. Good food for thought.

Interesting points in this article. The exact definition doesn't matter much. What really matters is the common understanding within a team of what technical debt is. It's also a good idea to be able to link it to actual money and business impacts.

It points out the security risk but it's mainly a good explanation on how Python loads modules.

Looks like a really neat tool for testing low level and kernel dependent details in a reproducible way.