2 ms·

At a previous job of mine, they implemented a "personal improvement plan" for employees who were below management's "desired productivity". There was no warning

At a previous job of mine, they implemented a "personal improvement plan" for employees who were below management's "desired productivity". There was no warning, no heads up that they would be measuring our GitHub accounts, and it had absolutely no context of what each person had been working on. These reviews came after a 360 peer review, and absolutely blindsided the team. Several of my coworkers left early for the day and didn't come in for the rest of the week. I got calls all day from various people asking what happened in my 1:1, what was said, etc... I wish I could show management how negatively and immediately that move affected the culture & mood of engineering at that company. It was an overnight change, and going forward it basically killed all trust in management. I stayed around for a little bit longer, but I should have quit the second they started those measurements. It absolutely murdered the confidence of our junior devs. Of the senior engineers who were put on it, none of them really had any idea what they were doing wrong or how to improve, as no feedback was given about any of that, just that they weren't enough. Some of our seniors had 15+ years of experience in software and were industry experts, but it didn't matter: They hadn't been hitting the number of commits and pull requests and tickets per week that management insisted on. When management was confronted about it, they admitted that code metrics aren't a good measurement of productivity, but then insisted that they "needed something". It turns out, they only used code metrics as a bludgeon to get rid of the employees they wanted gone, and since then that's all I've been able to see code metrics as. They're a battering weapon used to give HR a performance reason to justify firing you.

actsasbuffoon 7y ago
I’ve been a professional programmer for a while and worked at a variety of companies. When the teams I’ve been on decided to implement tons of metrics, it’s usually because we had tons of code quality problems. This was usually because we had inexperienced or inattentive programmers wreaking havoc. I currently work at a company where all the devs are pretty good and the code is decent. We don’t really need much in the way of metrics. If anything, we have more metrics than we should. I trust my current team to do the right thing more than I trust a linter.
gtirloni 7y ago
I'm sorry this experience left you scared of metrics but it doesn't mean they are bad, just that people need to know how to use them. I've had this exact conversation before and the extremism of "metrics are always weapons" was a contributing factor for me to leave a, say, less metrics-inclined workplace. Just saying there has to be balance.
- overgard 7y ago
  I've been a professional software developer for twelve years, and while I'm trying to keep an open mind, I have yet to see any useful metrics for what we do. Like, useful AT ALL. I can think of zero numerical metrics that can accurately tell you what's going on with a team. Number of commits, burndown charts, velocity, issues closed/created, whatever, they're all simultaneously easily game-able and also create bad incentives. And by the way this isn't sour grapes, metrics have almost always made me look good. One job I left, I had so many more commits than the next person that it took them two years after I left to catch up to me. And yet I'm absolutely certain I was not the most useful person on that team. The most useful person was the guy that was writing the extremely sophisticated modelling kernel, and if you only looked at the metrics he probably looked borderline useless, but in actual terms he was by far the most valuable and important person on our team. What scares programmers is, everyone on our team knew that, and any sort of manager with programming experience probably knows that, but you know that those stats are going to eventually float up to someone who doesn't know that the numbers are bogus. (After all, they wouldn't be tracking these numbers if they knew how bad they are). So decisions do get made from these numbers, even when people promise they wont.
  - Fire-Dragon-DoL 7y ago
    I'm completely with you on that. As for an example where some metrics might be useful: some form of complexity measurement of the code helps a new developer on the team discover where to poke to find out issues, as well as which parts are critical. While far from perfect, it gives you a starting point that's possibly better than "randomly open files in project". Now, this comes with interesting points: - the metrics in this case are in the hands of the professional in the field - the metrics are there to serve the person itself, without affecting others Metrics on commits, line of code, tickets closed are useless from my point of view. If you ask in a developer team who is weak at the moment (assuming there is no room for improvement is stupid) gives better results. A decent programmer is able to spot fake ones and is able to notice performance difference over time (not perfectly, but definitely better than metrics). Not to mention, I would be surprised if none of the team would start complaining if someone is doing no work and still getting salary. You can spend an entire day teaching your team something important about the project you are working on, have no commits about it. Or you can use half the day walking around thinking how to solve a bug. Not a single line is written, but that's how some problems are solved. I started counting in my working hours even when sometimes I wake up in the middle of the night and my mind solves programming problems for 1 hour (let's say). I have a decent employee, being at my desk typing is not what I'm paid for, I'm paid for solving problems with software engineering to the best of my knowledge.

actsasbuffoon 7y ago

I’ve been a professional programmer for a while and worked at a variety of companies. When the teams I’ve been on decided to implement tons of metrics, it’s usually because we had tons of code quality problems. This was usually because we had inexperienced or inattentive programmers wreaking havoc. I currently work at a company where all the devs are pretty good and the code is decent. We don’t really need much in the way of metrics. If anything, we have more metrics than we should. I trust my current team to do the right thing more than I trust a linter.

gtirloni 7y ago

I'm sorry this experience left you scared of metrics but it doesn't mean they are bad, just that people need to know how to use them. I've had this exact conversation before and the extremism of "metrics are always weapons" was a contributing factor for me to leave a, say, less metrics-inclined workplace. Just saying there has to be balance.

overgard 7y ago
I've been a professional software developer for twelve years, and while I'm trying to keep an open mind, I have yet to see any useful metrics for what we do. Like, useful AT ALL. I can think of zero numerical metrics that can accurately tell you what's going on with a team. Number of commits, burndown charts, velocity, issues closed/created, whatever, they're all simultaneously easily game-able and also create bad incentives. And by the way this isn't sour grapes, metrics have almost always made me look good. One job I left, I had so many more commits than the next person that it took them two years after I left to catch up to me. And yet I'm absolutely certain I was not the most useful person on that team. The most useful person was the guy that was writing the extremely sophisticated modelling kernel, and if you only looked at the metrics he probably looked borderline useless, but in actual terms he was by far the most valuable and important person on our team. What scares programmers is, everyone on our team knew that, and any sort of manager with programming experience probably knows that, but you know that those stats are going to eventually float up to someone who doesn't know that the numbers are bogus. (After all, they wouldn't be tracking these numbers if they knew how bad they are). So decisions do get made from these numbers, even when people promise they wont.
- Fire-Dragon-DoL 7y ago
  I'm completely with you on that. As for an example where some metrics might be useful: some form of complexity measurement of the code helps a new developer on the team discover where to poke to find out issues, as well as which parts are critical. While far from perfect, it gives you a starting point that's possibly better than "randomly open files in project". Now, this comes with interesting points: - the metrics in this case are in the hands of the professional in the field - the metrics are there to serve the person itself, without affecting others Metrics on commits, line of code, tickets closed are useless from my point of view. If you ask in a developer team who is weak at the moment (assuming there is no room for improvement is stupid) gives better results. A decent programmer is able to spot fake ones and is able to notice performance difference over time (not perfectly, but definitely better than metrics). Not to mention, I would be surprised if none of the team would start complaining if someone is doing no work and still getting salary. You can spend an entire day teaching your team something important about the project you are working on, have no commits about it. Or you can use half the day walking around thinking how to solve a bug. Not a single line is written, but that's how some problems are solved. I started counting in my working hours even when sometimes I wake up in the middle of the night and my mind solves programming problems for 1 hour (let's say). I have a decent employee, being at my desk typing is not what I'm paid for, I'm paid for solving problems with software engineering to the best of my knowledge.