A bit too high on the "positive caricature scale" to my taste. That said there's a kernel of truth there, focusing on the developer experience will lead to improved impact.

I had a few moment like this in my life. I definitely recommend it. I've never been more productive than isolated in a mountain with only books, notebooks and pens.

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

Interesting stuff, very rich I think I'll have to get back to it. This gives good clues and ideas of metrics to look at when evaluating teams output. Some of the findings confirm hunches which is welcome. It also shows that measuring productivity keeps being a messy business, there are so many factors influencing it in some way.

This is a funny but interesting productivity tip.

A good reminder that long hours are not a sign of success with your project... on the contrary.

Indeed, it's hard. You need to put in the work but it's hard to predict where the real value will come from.

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.

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...

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

Good summary of the different possible options around remote work.

Looks like the productivity gain promises are still mostly hypothetical. Except on specific limited tasks of course but that doesn't cover for a whole job. Also, when there is a gain it's apparently not the workers who benefit from them.

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).

Trying to measure individual productivity is definitely a trap. You'd better not try, otherwise you'll have wrong behaviors or you'll punish the wrong persons.

We should definitely put the 10x engineer myth to rest. Let's focus on setting up the right organisation and culture instead.

People really need to be careful about the short term productivity boost... If it kills maintainability in the process you're trading that short term productivity for a crashing long term productivity.

Again it's definitely not useful for everyone... it might even be dangerous for learning.

Be wary of the unproven claims that using LLMs necessarily leads to productivity gains. The impacts might be negative.

It's indeed tempting to conflate the two (at least for marketing purposes apparently, I see you LLM vendors...). Even if tempting, developer experience is definitely not equivalent to productivity.