Things which matter take time. The calls to productivity and technology pushing us toward faster response on everything is killing what makes our humanity.
I mean, with the announced productivity gains of generative AI... It doesn't feel like a big ask. đŸ˜œ
Or why most of the studies we see out there can't be trusted. They're full of holes and flaws. We'd really know people who know what they do in humanities to conduct such studies to get a chance at a proper picture.
The title is a bit too much of a blanket statement. Still there's indeed a lovely no between pair programming and merge requests. If possible you should favour the former. Yet it rarely happens in practice, there are reasons for that.
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.
A bit of a stretched metaphor in here, but indeed being individually faster doesn't automatically make the team faster. Sometimes quite the contrary in fact.
Long but very precise piece about why you can likely ignore LLM for development purpose. Starting from older Fred Brooks work is spot on. Indeed whatever will remain of LLM based tools in the years to come, it's much smarter to focus on fundamental skills than chase the new tools. At least, I'm trying to do my share in getting myself and others better at the craft.
So much this... There are so many organisational problems that churning code faster is likely not what you need. When did we start to obsess with the number of lines of code?
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.