There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?
Maybe engineer #1 is constantly pushing up code. In the time it takes them to merge 15 PRs, engineer #2 opens only 1 - but maybe they thought really deeply about the problem, and their approach actually saves the team hundreds or thousands of hours of future development work vs how engineer #1 would have solved the problem.
Part of what makes this so hard to measure is the long tail effects of development decisions. (Incidentally, that's also a source of burnout for me - the constant mental overhead of worrying about the long term implications of what I'm doing, and particularly how they effect other people. It's very challenging.)
There are some core areas of the application that are much more important, but they are often the earliest data structures and built before the problem is known. You will not know how your code will change, so make it as consistent as possible with the rest of the system until you know more.
The most productive fpga engineer I ever hired was so hopeless with git that I had to hire a second software engineer to babysit him.
After I left both of them got fired and the product they were ahead of schedule on when I left had slipped 2 years behind before it finally got cancelled three years later.
Overall I don't know if, in the context of a staff developer, he's vastly more productive than say, another dev I have who produces less but levels-up his team better than almost anybody I've ever seen.
The issue is when metrics are used to stack rank teams with no thinking put into it. You can't treat correlated metrics like direct metrics. A logger might be evaluated based on how many trees he cut down in a day. There is no comparable way to pay software engineers piecemeal.
Metrics are good, but people want to use them without thinking or taking context into consideration.
* MVP doesn't count.
** Can include users inside the organization.
*** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.
I also worked for hardware companies, where shipping stuff had some pretty serious stakes, and learned how to make sure we got it as good as possible, before getting it out the door.
I like the idea of evolutionary design, and "tuning," but I think it's a bad idea (for me) to deliberately ship bad software as an end-product.
(Also, MVP, by definition, generates lots of trouble tickets. I am allergic to trouble tickets. It's totally a personal thing, but I live by it).
In fact, my way has been working for me, for decades.
I'm quite aware that many folks do it differently, and that's one reason that I try to "keep it in the I," and write about how I do it, and talk about the bar that I set, for myself.
Most of the software I write, is free software that Serves a pretty small demographic. It can have a fairly outsize influence on the lives of the people that use my software, and I really care about the end-users of my work, so I tend to set a pretty high personal bar.
I'm quite aware that I don't have many of the stressors that beset commercial software houses, so I sincerely don't feel "snooty." In fact, I feel profoundly grateful to be in a position, where I can follow my muse.
I really would like it if folks wrote better stuff, but I am also aware of the culture, and how that's next to impossible, these days.
"They'd beg to work for us" - what the f8ck.... if they were the best they would not beg anyone how degrading...They would be there for a mission or wanting to improve something about themseves or other parts of the world.
There's nothing here apart from Agile coach wanting to get some more work.
1984 was released in 1949, if anyone thinks these words / values really mean what is writen wow. People, Internal Quality, Lovability, Visibility, Agility, Profitability...