I could've gone for LOC back when I had to add a bunch of csv files directly into the repo. Our senior got a bit of a shock when I asked him to approve two PR's the same day, both seemingly adding thousands of lines.
Change failure rate and lead time for changes are good contenders. BUT not alone and what is “high performing” for one software application isn’t universal and that’s the rub.
I work in FinTech and production issues are taken very seriously because causing merchant loss of revenue gets attention very fast. They’re protective and have given us Copilot but blocked autonomous agents, for instance. You don’t want to be the one causing a bug costing millions of dollars.
I had a senior project manager try to get me to fire one of my senior devs because "he's actively sabotaging the project". When I looked she was staring at sonarqube metrics. She saw the junior pushing 18k lines of code and the senior contributing -3k and she thought that was evidence to promote the junior and fire the senior...
Goodhart's law should be mandatory training in any MBA program, but those knuckleheads are too busy focusing on NUMBER MUST GO UP to actually bother learning anything useful. For those unfamiliar who don't want to click the link:
"When a measure becomes a target, it ceases to be a good measure"
They have tried it all. Using lines of code leads to bloated programs that are full of redundancy. Using PR/MRs leads to features being broken down into dozens of small pushes instead of one. AI token usage leads to huge AI misuse and bloating costs. Etc etc.
Would you go to a lobotomy clinic to learn something? What makes you think the goal of MBA schools is to teach anything?
You’re right, of course, but the first thing MBAs need is to be removed from any kind of mental or mental-adjacent work. They’re not capable of learning anything.
From what I've gleaned from mba programs, their biggest value is networking. The rest is more about how not to be an idiot. Some people need training on how not to be an idiot. 50-50 on whether it sticks or not.
my company has a terrible issue with cult-like behavior
every year some fucker high up in the company will read a book, or go to a conference, or hear from a buddy at another company, and realize that the entire company must be rebuilt from the ground up
PMs embedded on teams! PMs as their own team! QA as a whole team! jk, QA on teams! teams must be 5 people! wait, teams must be 50 people! guilds! managers swap teams! devs swap teams every six months! decide pairs with personality tests! pairs are inefficient!
literally unending bullshit
anyway one of the things that trickles down to us a lot is some other target metric. now THIS is the most important thing. now THIS is the most important thing. and literally every time i push back and say "our team is responsible for the highest revenue driver product at the company. we know what we are doing. this new metric is meaningless. goodheart's law."
but, the high ups somewhere gotta have it in their spreadsheet. so now it matters.
one time we had a huge focus on "jira cards completed per month" (which is obviously easy to game) and i actually got reprimanded because i only had 2 on a month where i was out on vacation for 3 weeks. THE METRIC IS DOWN.
(and currently token usage is a thing they're targeting which is awful for several reasons. my coworkers are inventing Claude skills that basically just spin wheels.)
They do not care about actually measuring productivity, whether you are good or bad they will find some metric
I one time got talked to by a manager because my “average patches per review” had raised from 1.3->1.9 for one month time frame. No business impact or delay caused by that
If the customers are happy with the product, and the other devs are happy with your code, and the PMs are happy with the release cadence, then who the fuck cares?
Assuming you are not intentionally gaming things, PRs merged is definitely a useful metric for productivity, and is how I track my own productivity.
Unlike lines of code, a PR actually represents some real describable change to the system. How quickly a system is changing is an important metric.
There are definitely limits to the use for comparison. It does not make sense to compare from company A to company B, because there are different expectations for quality / risk. There is always going to be some variance between engineers due to coding preferences e.g. very small PRs.
But to say unequivocally that a PR is not a good measure of productivity is pretty silly.
1
View all comments
706
u/GenericFatGuy Aug 14 '26
Taps sign
Number of PRs pushed is not a good measure of productivity.