Thoughts about how to measure developer productivity.

I found this useful when I read it all those years ago. Start from there, find other views from project managers or other developers or whatever and synthesize the literature to form a rounded/deep opinion on some of the ways we might actually measure the real thing. Of course I expect us to "fail", but just fail better than the current incumbents and try to make a small dent into the structure of the problem.

https://sourcegraph.com/blog/developer-productivity-thoughts

OTHER RANDOM IDEAS - NOT WELL INFORMED

• Read the mckinsey report and the many articles written in response to it.

After looking around a bit however, I'm back to the purpose of "wakana". This project is not about measuring developer productivity but rather server as a magnifying glass on what developers are up to. That is in our opinion even more valuable especially with the rise of LLMs and agentic coding or chat oriented programming or whatever.

Now productivity is not just measured in volume, but rather quality. The bar is rather high these days for quality since you can know more about your ORM, or graphing library from an LLM. In fact, the LLM can build a prototype that will help you speed up your "inner loop" activities even better. At the end of the day, productivity is no longer volume oriented - (no. of PRs and such). but more quality oriented.

A new challenge now is to define what Quality means.
Better DX, less time to review PRs, less time to make PRs, useage metrics.

• What is software work quality
• How do we measure this

Some quality metrics

• Focus time - heartbeats represent developer activity. The more concentrated this activity is within a period of time the greater the focus. We should, based on information gathered, come up with classifications for different kinds of "focus". We should also
• Breaks during working hours - More coding breaks than usual?
• Deep work per day - Better metrics to be derived from "Focus Time" above. Deep working hours may now be determined - based on to be decided focus time threshold and duration.

But what does this quality oriented-ness mean and what does it involve and how do we measure some of these qualities.

It feels as though organisational bottlenecks might now outweigh developer inefficiency or slack. Serious companies were able to hire more developers than they needed in the past so some could pick up the slack while others got burned and went on holidays. Now they hire even less developers and still do more. In the end some organizational bottlenecks like

• Whether there is a staging environment
• Whether team members can deploy to staging with ease - not requiring another more senior dev to signoff on that
• Whether there are enough tests for critical functionality
• Whether there is CI/CD setup
• Whether deployments are also automated and the ease and reproducibility of deployments
• Amount of tech debts - probably measured via bugs/issues ratio?