2 ms·

There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should b

There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should be used with caution. There are qualitative measures like code maintainability, satisfaction of stakeholders, communication skills, system design skills, etc. Those have to be assessed using peer feedback, stakeholder feedback, 1-on-1's, activity during calls and meetings and so on. Those are harder to measure, but also harder to game.

n4r9 2y ago
In my experience, not only are quantitative metrics gameable, but they depend greatly on accurate estimates (which just shuts the problem along) and tend to bias towards rushed implementations. You also have to be very careful to consider what duties the person has beyond pure coding, which can become time-consuming as they grow in seniority, such as mentoring juniors, engaging with product teams, or supporting product enquiries. The qualitative measures you mention describe "quality" rather than "productivity" (rate of good output). Both are aspects of performance, but are definitely distinct. I suspect that the best you can do for productivity is kind of a halfway house, where - as part of their feedback - a more senior developer indicates whether the rate of implementation met/exceeded/fell below expectations.