Good approach, you indeed need to immerse yourself in the context and see the recurring patterns. That's the best way to figure out impactful solutions to recurring issues.

Some of it is probably a bit too cynical (often the case with this author), and yet it has good advice on how software engineers influence the organisation around them.

Good check list of things to consider when you're delegating something. It's pretty much the expectations from the person who delegate to you.

The responsibilities drop on people before they're ready for it (I see it first hand regularly at customers). Such tips are thus welcome and helpful during the transition.

This is a short one but a good one I think. Helping others to do rather than doing directly is the needed shift to get into technical leadership. It's not an easy leap though, been helping some people getting there and it's quite the effort.

Short and to the point reminder: our job is never only about the tech. It always encompass some people related concerns, be it inside teams, between teams, or the impact on the users.

Cryptic title to be honest. But this is a good explanation of why any "agile transformation" better start close to the code and in particular with automated tests. If you can crack that nut (and it take time), the rest will follow naturally.

So much this... There are so many organisational problems that churning code faster is likely not what you need. When did we start to obsess with the number of lines of code?

Lots of good insights in here. Of course YMMV and some definitely depends on your context. That's a lot of dimensions to keep in mind though.

Interesting framework of different leadership styles. They all come with their own pros and cons of course.

The point is interesting. Priorities are indeed relative and dynamic. It's impossible to put an "absolute priority value" on what needs to be done.

Interesting comparison of Drucker's and Deming's approaches to management. One is easier while the other is clearly demanding but brings lasting improvements.

Nice advice, there's a lot of variation on the role. And yet, some things seem to always be there.

This is a good overview of what the Staff Engineer can be. There's of course a lot of variation depending on time, priorities and the culture of the organisation.

Feels a bit odd to go to such length to put it in numbers. And yet, it's clear that friendships in the workplace are a must. They should be fostered rather than stifled.

Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.

This has been documented for a long while. Of course, it's been followed by an unhealthy fascination for the "Toyota way". This kind of cargo cult of course lead you nowhere to doing things properly. And yet, now that the dust settled, there are good lessons to learn from Toyota management back then.

I think this is a good pick at a core skill for senior developers. Indeed removing ambiguity for the rest of the team is an important factor.

This is very true. It's not like whoever produced bad code is particularly stupid, in most cases it's the context around which breaks the people.

It's indeed not just about the label. It's more about behaviour.