Some areas of our industry are more prone to the "fashion of the day" madness than others. Still there's indeed some potential decay in what we learn, what matters is finding and focusing on what will last.

An old one and a bit all over the place. Still, plenty of interesting advice and insights.

Interesting thinking, indeed expectations are changing quite a bit for engineering managers over time. Thus the proposed list of core and growth skills is interesting. It is likely a good framing for the job, then the art is finding the right balance for your organisation.

I'm not really a fan of the leaderboard part of their approach. That said, if the maturity of the organisation allows it, having such bug squashing sessions is a good idea.

Definitely this. It's a good reminder of the boy scout rule. It's fine to clean up as you go and when you find the opportunity.

I like the approach. Indeed what matters is to have visibility, don't weaponize measurement otherwise the trust will falter.

I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.

Nice list of templates to use for better handling of engineering management in your organisation. Pick, choose and adapt what makes sense to the context.

I like this article. Indeed, focus on building organisations and teams where it's easy to do the right thing bit hard to fail. This is much better than obsessing over mythical 10x engineers.

Interesting findings about procrastination. Some effects were expected, others less so. The actions to avoid it in teams should be well known now.

Looks like a good approach to integrate LLMs in your development workflow. In case that would become something trustable.

Interesting ways to look at processes and their outcomes. Depending on the mental model you won't ask the same questions when investigating incidents.

You can't be in the backseat when using those tools. Otherwise you might feel productive by cranking out code but it can't do the essential tasks for you (most notably actual problem solving or architecture thinking). The quality would clearly suffer.

Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.

There are clearly more to know. But this is a good list already.

This opinion piece is getting old... and yet, it doesn't feel like our professions made much progress on those questions.

This is indeed almost always leadership you need in your organization. An engineer who want to manage, maybe be careful about their skills and motives.

A bit of a self-serving post towards the end. Still I like it because it clearly mention that it's not about dropping all documentation in favor of the code (quite the contrary in fact, documentation is very much needed). It really is about treating code like documentation, putting the same care into it in terms of readability and understandability. If you wonder what code reviews are for... it's also for this readability concern.

This is a good list of skills and behaviour to develop if you want to get better at our craft.

For sure the aforementioned manager need to fix his communication style. That being said the core advice was indeed good.