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.

This is an account of how dark things can become when you align your identity with your contributions. Stay healthy, stay safe!

I agree with this very much. The only productivity metric in the end is the end-user satisfaction.

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.

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

It's fine to surround yourself with people smarter than you. It's a good thing... except if they are competitive. Then it can become a curse and kill your motivation.

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