Are there any actually useful metrics for developer performance? /u/Whitey138 CSCQ protests reddit

I’m a developer for a VERY large non-tech company (you’ve heard of them and might even know the CEO by name). In a recent team meeting, my manager let us know that the higher-ups have a metric that they use to see our “performance,” however I am told that they don’t ACTUALLY judge us on it when it comes time for a review, they just like to look at it (a lot of the wording seemed fishy). The metric is number of commits. I don’t agree with this and don’t feel like it is a useful window into how effective we are at our job. The person at the top of the list for our team is constantly pushing junk, then fixing small things in that initial commit one by one. He also is responsible for making config changes, which are often done almost blindly: commit a change, deploy, fails, commit another change, etc. until it MAYBE works. I, on the other hand, am the opposite where I have MASSIVE commits. I am aware that the way I’m doing it is not ideal and I can change how I approach commits (since I was towards the bottom of the list) however it makes me wonder if there is a better metric that is actually useful for measuring developer performance. Every one I can come up with has massive drawbacks.

Here are some metrics I can think of and my concerns with them:

Lines of code – Great way to get massively unmaintainable garbage (my team recently inherited a bunch of code from another team and it seems like this is what they were shooting for; think 3000 line JS files with 200 line functions that barely even work and are terrible to debug).

Number of commits – Tons of useless commits that don’t do anything making looking at a commit history a nightmare and making the history of our repos take forever to load in browser.

Number of tickets closed – This will mean nobody will want to take on larger tickets since they can get more manager brownie points by doing a lot of small tasks.

Number of story points – This will most likely (and I’ve seen it happen in the past) lead to story point inflation. Everything that was 2 points is now 3 and everyone is tripling their capacity. Pointing then becomes irrelevant (if it wasn’t already, but that’s a different discussion).

Number of bugs fixed – Similar to the classic story of writing system.sleep(10) then removing it later to speed up the system; writing a bunch of bugs intentionally just to remove them one someone finds them. I have had the lowest number of bug fixes because I thoroughly test my work before handing it off to anyone.

I am aware of the saying “Once a metric becomes a target it ceases to be a good metric” and I agree but I’m curious if there are any that do a “pretty good job” without being completely useless or game-able. Does anyone have any actually useful metrics that have worked for you? Am I completely out of line in my thinking? And no, I’m not quitting my job (finding a new one right now scares the crap out of me).

I’m a developer for a VERY large non-tech company (you’ve heard of them and might even know the CEO by name). In a recent team meeting, my manager let us know that the higher-ups have a metric that they use to see our “performance,” however I am told that they don’t ACTUALLY judge us on it when it comes time for a review, they just like to look at it (a lot of the wording seemed fishy). The metric is number of commits. I don’t agree with this and don’t feel like it is a useful window into how effective we are at our job. The person at the top of the list for our team is constantly pushing junk, then fixing small things in that initial commit one by one. He also is responsible for making config changes, which are often done almost blindly: commit a change, deploy, fails, commit another change, etc. until it MAYBE works. I, on the other hand, am the opposite where I have MASSIVE commits. I am aware that the way I’m doing it is not ideal and I can change how I approach commits (since I was towards the bottom of the list) however it makes me wonder if there is a better metric that is actually useful for measuring developer performance. Every one I can come up with has massive drawbacks.

Here are some metrics I can think of and my concerns with them:

Lines of code – Great way to get massively unmaintainable garbage (my team recently inherited a bunch of code from another team and it seems like this is what they were shooting for; think 3000 line JS files with 200 line functions that barely even work and are terrible to debug).

Number of commits – Tons of useless commits that don’t do anything making looking at a commit history a nightmare and making the history of our repos take forever to load in browser.

Number of tickets closed – This will mean nobody will want to take on larger tickets since they can get more manager brownie points by doing a lot of small tasks.

Number of story points – This will most likely (and I’ve seen it happen in the past) lead to story point inflation. Everything that was 2 points is now 3 and everyone is tripling their capacity. Pointing then becomes irrelevant (if it wasn’t already, but that’s a different discussion).

Number of bugs fixed – Similar to the classic story of writing system.sleep(10) then removing it later to speed up the system; writing a bunch of bugs intentionally just to remove them one someone finds them. I have had the lowest number of bug fixes because I thoroughly test my work before handing it off to anyone.

I am aware of the saying “Once a metric becomes a target it ceases to be a good metric” and I agree but I’m curious if there are any that do a “pretty good job” without being completely useless or game-able. Does anyone have any actually useful metrics that have worked for you? Am I completely out of line in my thinking? And no, I’m not quitting my job (finding a new one right now scares the crap out of me).