I read a thread on Blind that some companies use diff count, number of PRs, comments on PRs etc to measure developer performance. This got me curious to ask the question
It's weird to me how companies use a form or forms of code counting to measure performance.
For example, if you measure my performance on the number of PRs, I'd attempt to create as many PRs as possible even at the detriment of productivity for the team.
If you measure me on the number of lines of code I write, I will deliberately write code that maximizes the number of lines even if the quality of my code goes down. And I will sign up for tasks that I think will allow me to easily write a large number of lines of code even if it isn't the most important tasks for the company.
Can we really measure developer performance using discrete code numbers?
I've always found that it's better to measure performance through the following means:
1. Are you making improvements to the code?
2. Are you completing projects on agreed time? If not, are you giving valid reasons for why they're delayed?
3. Are you giving accurate and sensible estimates for projects?
4. Are you helping the team?
To that, I believe you can make some OKRs:
* Research and implement x ways to speed up the web app
Exactly this. If you devise an intrusive, visible system, people will game it to their advantage, that's a very fundamental rule of life.
I would consider it part of a team lead and/or project manager's roles to be evaluating those points you posted and to be in regular dialogue with people so that they have a general picture of what people are up to at any given time.
When you listen to what people say they're working on week after week and observe the quality of their outputs for a few releases, you tend to get a feel for how they work. What's the point of having middle management if not to be close to developers anyway?
At the moment we're having to account for every hour in the work day by entering it into a plugin in jira. Kind of a pointless exercise, but management is out of ideas and needs to justify why projects are super late and thinks it will help.
Other than that, we have annual goals which each have completion criteria which we're evaluated on.
3 comments
[ 0.22 ms ] story [ 22.5 ms ] threadFor example, if you measure my performance on the number of PRs, I'd attempt to create as many PRs as possible even at the detriment of productivity for the team.
If you measure me on the number of lines of code I write, I will deliberately write code that maximizes the number of lines even if the quality of my code goes down. And I will sign up for tasks that I think will allow me to easily write a large number of lines of code even if it isn't the most important tasks for the company.
Can we really measure developer performance using discrete code numbers?
I've always found that it's better to measure performance through the following means:
1. Are you making improvements to the code?
2. Are you completing projects on agreed time? If not, are you giving valid reasons for why they're delayed?
3. Are you giving accurate and sensible estimates for projects?
4. Are you helping the team?
To that, I believe you can make some OKRs:
* Research and implement x ways to speed up the web app
* Complete x number of medium sized projects
* Complete x number of large sized projects
* Review x% of PRs within x amount of time
I would consider it part of a team lead and/or project manager's roles to be evaluating those points you posted and to be in regular dialogue with people so that they have a general picture of what people are up to at any given time. When you listen to what people say they're working on week after week and observe the quality of their outputs for a few releases, you tend to get a feel for how they work. What's the point of having middle management if not to be close to developers anyway?