A bit more nuance in the "how to use the lines of code metric?" debate. Indeed it's not the same if you look at complexity or productivity.

Obviously the essay from Peter Naur keeps popping up lately. It feels like an important piece, especially in the current atmosphere of vibe coding. This article lays out quite well why vibe coding is the opposite of what we should be doing.

Rampant complexity in software is also a management issue. Are we sure we're rewarding the right things?

Very good essay on why the developer profession is not going away. On the contrary we need to double down on essential skills and put in the work. This is long overdue anyway.

Quite some good tips in there. If you want to do deep work you need to arrange your organisation for it. Using asynchronous communication more is also key in my opinion.

Everyone makes mistakes, what matters is how you handle them.

I used to do that, fell into the "taking notes on the computer". And clearly it's not the same, I'm thinking going back to paper notebooks soon.

Interesting insight. Gives a lot to ponder indeed. Focusing on technical debt alone probably won't improve a project much. It's thus important to take a broader view for long 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.

This is good advice. To improve your organisation, focus only on the biggest constraint. Otherwise you'll quickly be spread thin.

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.