The example is maybe a bit on the simplistic side. Still it helps understand why you need to pay attention to the SRP.

Interesting idea. Didn't make one but maybe I should sit and take some time to do that.

A short list of common code smells that people need to know.

Indeed, you can't trust claims of the big cloud players. If asked by they will hand out your data, wherever it is hosted.

Or why you should know why you're picking a new tech stack... or not. Don't just blindly follow fashions.

Or why the microservice cargo cult which has been going on for a while now infuriates me. It totally ignores the complexity it brings.

Or why meeting targets is not what you want. It's still a good guide though.

Interesting trick for remote teams. There are many ways to try to get back the "water cooler talk" in your organization, it's the first I encounter structured like this.

This is an old one, but I think that even without DVDs in the mix the core of the stories are still valid.

When you realize TDD is about units of behavior... then you can see what can be iterative and what can't in your process. In other word, what is dictated by the problem domain is iterative, what is dictated by system architecture is not. Luckily, the latter is often related to the user experience you're aiming for.

The question is always valid. I like this particular answer.

It's indeed not only about skills but also about roles... and the natural tendencies to cover them.