The executive summary is good. This is also a nice source of reference papers and studies on the topic. It shows quite well why the work is moving to the harnesses rather than the models. Indeed models probably won't improve much in terms of reliability. It all points once again towards a needed shift of people attention from the shiny toys and towards team practice instead.

Very good opinion piece going back to Naur's and Brook's important papers about software production. It's a sobering take on how LLM can't bring the promised productivity gains. This is not saying it can't bring productivity gains of course but it'll never be as dramatic as what the current hype cycle pushes people to believe.

I like this article somehow. Indeed I'd like to see more guilt in the people shipping bugs in production (myself included probably). Also I'm very much aligned with the proposed approach to tame issues: thinking, types, tests, and telemetry.

Excellent piece about code reviews. But it goes further than that and shows how our skills could improve. By tackling this question it does a good job showing we don't know where the ceiling is in terms of skills in our craft.

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.

Very interesting series I previously missed. It explores if software engineering is really engineering, and the differences with other engineering fields. Quite a few nice lessons to draw from it.

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.