Nice illustration on how you can hunt down complexity in your codebases. It is obviously a slow process but comes with nice benefits.

Indeed feels bad when there are so many problems in the example of LLM based completion you put on the front page of your website...

Nice piece. In an age where we're drowning in bad quality content, those who make something with care will shine. They need to be supported.

If you expected another outcome on the average developer job from the LLM craze... you likely didn't pay attention enough.

It definitely has a point. The code output isn't really what matters. It is necessary at the end, but without the whole process it's worthless and don't empower anyone... It embodies many risks instead. I think my preferred quote in this article is this:
"We are teaching people that they are not worth to have decent, well-made things."

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

This is a good rant, I liked it. Lots of very good points in there of course. Again: the area where it's useful is very narrow. I also nails down the consequences of a profession going full in with those tools.

Somehow not surprising... There's an area where it works OK. That said, I think we don't have the right UX to exploit it safely and productively. The right practices still need to be found. This isn't helped by all the hype and crazy announcements.

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.

Such contributions still don't exist. Or their quality is so abyssal that they waste everyone's time. Don't fall for the marketing speak.

We often hear that question about the trade off between quality and cost. The question is badly framed though. If it's low quality it's requires more effort to add or change features... and so it's more expensive mid-term (not even long term).

Nice post. Explains well why the answer is not a number to target. You want to impact the distribution.

Interesting thinking around a portfolio of activities. You can prioritise differently within it to manage quality vs speed of delivery over time.

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.

When I read the content of this article I wonder how useful the metrics really were. I mean clearly they helped the team realize which changes to bring... but the practice changes were all somewhat conventional in a way. You go a long way when you focus on quality and create the space for it.

This is clearly not a great outcome. The browser monoculture probably doesn't help.

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

Maybe we could store metrics about the code in the history as well? This would indeed reduce vendor lock-in. This tool makes it easy. Unsurprisingly seems built upon git notes.

Interesting musing about the "software crisis" which was declared in the late 60s. We're coping with it by piling levels of abstractions but clearly we're still not out of it. Our craft still needs to grow.