This is a good reference on how to write design documents. It's not as easy as it sounds sometimes, and this guide contains good tips.

Sometimes, you got to deliver the bad news... It's healthy if you feel uneasy about it though.

Good overview of why we don't see a speed up in development processes when AI tools are introduced. The bottlenecks don't magically get destroyed.

Looks like an interesting reference of patterns in software engineering.

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.

This feels a bit too realistic for my taste... and yet... Well this piece of satire is well crafted I'd say.

Clearly, any endeavour which has to scale will need some form of bureaucracy to stay afloat. The art is keeping it to a minimal before it starts to be an end in itself.

Those have no name... but you'll encounter them regularly indeed.

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.