6 ms·

Reminds me of a story I heard from a friend. Some consulting firm came in to the company and decided, based on number of commits (or some such metric), that on

Reminds me of a story I heard from a friend. Some consulting firm came in to the company and decided, based on number of commits (or some such metric), that one particular engineer was the lowest performing engineer on the team. So, management fired them. Turns out that engineer was the one who everyone side-channeled with to get help when blocked. They were the one who knew the system best and were enabling everyone's productivity, it just didn't show up in the metrics. I wonder how many false positives they got here.

hashkb 5y ago
Flip side: engineers who curry favor without delivering value can't hide it quite as easily. Those who do their jobs without sucking up have a chance for recognition.
- MathYouF 5y ago
  It's pretty cynical to view the person who is helping others get unstuck as "currying favor". In every place I've worked, the person who has helped me get unstuck has always been one of the most productive and talented members of the team. If they weren't, why would I need their help?
  - planet-and-halo 5y ago
    A guy at my job is a gamer and describes it as "buffing the group." Just as in a game, the healer could be the team MVP, but if you measure DPS you are never going to realize it.
    - hashkb 5y ago
      The healers are usually the best players. They'd be better at DPS but everyone wants to be DPS and demands heals constantly. Source: was a priest in WoW back in the day. Because nobody else wanted to, not because my warlock sucked.
  - hashkb 5y ago
    Not what I'm saying. I'm saying there are plenty of terrible engineers coasting and this will catch them. Edit: I've been top of regular productivity charts AND the unanimous answer to "who do you go to to get unstuck?" at at least one company you've heard of. Management regularly promoted the suck ups. Read something like Blind and you'll know how prevalent this is.
    - MathYouF 5y ago
      Well I take your point and trust that you are productive and well respected by your peers. I guess you mentioning that the flip side of the false negatives is the true negatives (people with low performance metrics who haven't been fired yet due to kissing up) is a correct response. Sorry for the misunderstanding. I thought your flip side was an alternative perspective on those who help others get unstuck, not on those caught by the HR performance metrics filter.
      - hashkb 5y ago
        I'm happy to get people unstuck. It's the best for everyone and the company. I hate when a "growth hacker" moves a meaningless metric an insignificant amount and gets a bonus so some middle manager can get up and claim a "win" that makes more work for me and my team but costs the company money.
hncurious 5y ago
Result: git committing, excessively.
- ARandomerDude 5y ago
  And stop squashing.
  - lumost 5y ago
    I work at a company where code activity is reviewed from time to time by individuals who are at least somewhat familiar with the breadth of activity an Engineer does. Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.
- 908B64B197 5y ago
  Reminds me of someone. Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him". Three promotions in 18 months and jumped to a FAANG not long after.
  - abledon 5y ago
    sounds like hell, but at the same time, he is a legend.
  - geoduck14 5y ago
    If getting a promotion really is as easy as committing lots of lines of code, and you are THE ONLY one to figure it out, then you deserve a promotion
AmericanChopper 5y ago
An old boss of mine used to acknowledge people that had contributed excessively high LoCs at the weekly standup. Typically it used to be an indicator that somebody had completed a large portion of work. Then a new guy started topping the LoC charts every week, and it was discovered that he was reformatting every file he touched to use his preferred indentation scheme. It was a pretty lighthearted thing to begin with, but they stopped mentioning it entirely after that.
- combatentropy 5y ago
  In 1982 Apple was having programmers report lines of code. Bill Atkinson refactored Quickdraw and put down a negative number, -2000 lines of code. Then they stopped asking him to fill out the form. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
gricardo99 5y ago
Indeed, some SCM metrics could be used to reach exactly the wrong conclusion: lines-of-code add/removed. Oh my gosh! Jonny coder over there has been deleting, deleting! our code. Fire him immediately! Many years ago there was a discussion on HN about that same topic[1] (And since then many more I'm sure). 1 - https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815
- opinion-is-bad 5y ago
  Simpson’s Paradox takes many forms. If your sampling or measurement criteria are wrong, even subtlety, then the results are nonsense without anyone knowing. Practicing statistics in an area for which you are not an expert is almost always a bad idea.
- _tom_ 5y ago
  Dilbert is relevant: https://dilbert.com/search_results?terms=Write%20Minivan https://dilbert.com/search_results?terms=Write%20Minivan Metrics are frequently inaccurate and easy to game.
  - xsmasher 5y ago
    A decade earlier, this story at Apple https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- croes 5y ago
  Maybe that's the reason why programmer using spaces instead of tabs earn more money. They get payed by file size
akg_67 5y ago
LOL, reminded me of my own case. I had the fewest issues closed and longest time to close owned issues. But my boss knew the reasons and was very understanding that I was acting as escalation point for the team. It was the upper management, who was lead by a bean counter CEO, couldn't understand why I was still around with such low productivity. Saving grace was my boss and sales people who kept hearing good things about me from customers.
- 908B64B197 5y ago
  > it was the upper management, who was lead by a bean counter CEO, couldn't understand why I was still around with such low productivity. Career red flag right here.
TeeMassive 5y ago
At a company I used to work the manager of our next money cow project promoted the 2-4 people who committed features the fastest. They were "10 times as fast" as the others and therefore it made sense for him to give them the title of "architects" and give them veto power. Turns out they spewed out the most ugly, over-engineered and unmaintainable code that all the others had to fix/maintain/understand their mess.
blululu 5y ago
Reminds me of a classic story about Bill Atkinson back in the 80's: TLDR; Management was counting lines of code as their metric of productivity. Which was great until someone actually cleaned up the code base and added -2000 lines of code. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
908B64B197 5y ago
Spoken from the man himself https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
bgro 5y ago
I was the go-to on almost every team at my last job when there was a hotfix, major risk change, security fix, etc. I knew the whole system pretty well and knew how to find and match up our awful logging to actual code and find the flaw far faster than anybody. I'd develop and test a fix and quietly discuss with that team's tech lead about risk vs reward concerns to see if they agree or want to discuss changes, then I'd get a pull request out there. The management / executive team would always hear about major crisis hotfixes, then immediately see my name on the high visibility pull request. Thus, they think I personally must have been the cause of the problem. Somehow I was on every team and responsible for every feature, every hotfix, and the poor work every team developed that irritated clients. (Funny how I was never responsible for the positive things, though.) Then there'd be companywide meeting / email to cover what happened with a screenshot with my name by a hotfix with comments like "Let's not have to do things like this going forward." "Some of us have to actually work for a living, and heh I don't know about you guys but _I_ don't appreciate having to panic review things like THIS!"
- pts_ 5y ago
  Career management enters the chat. Play blame game nothing gets done.
  - mgh2 5y ago
    Management had low understanding of correlation vs. causation. This reminds me of one of Udacity's first classes: do firefighters cause fires? https://www.youtube.com/watch?v=Ku9E9uKyr4E https://www.youtube.com/watch?v=Ku9E9uKyr4E
- bonzini 5y ago
  Sometimes I have seen the opposite problem, where people look like they do not have enough engagement in customer cases, because most of the bugs are ironed out before the new release is announced.
ssss11 5y ago
Similar to an experience I had in my first job - repairing electronics (pcb’s, components, tuning radios and lasers) for supply chain environments and we were (loosely) reported on via how many jobs were completed per day and the average for a technician was somewhere around 5, so 25 per week. The experienced technicians would leave the base stations though as they took a long time to troubleshoot and repair, so customers would get upset that the turnaround was slow. But these repairs were also profitable because extra labour and parts margin. So I would take them on - win/win I thought - happy customers and billing the expensive jobs, heck someone has to do these jobs. The problem was that you couldn’t complete more than about 1.5 of these jobs per day on average. Anyway, new lab manager comes in, crunches numbers and they decide my work rate is too low and I’m no longer required… I still wonder to this day if it had an impact on turnaround of those devices.. I would like to think they realised what they did. I also learnt not to get too far from the herd even if you have the best of intentions.
pts_ 5y ago
Reminds me of a CEO who proudly thought technically knowledgeable friends are good to get ideas from but not hire.

hashkb 5y ago

Flip side: engineers who curry favor without delivering value can't hide it quite as easily. Those who do their jobs without sucking up have a chance for recognition.

MathYouF 5y ago
It's pretty cynical to view the person who is helping others get unstuck as "currying favor". In every place I've worked, the person who has helped me get unstuck has always been one of the most productive and talented members of the team. If they weren't, why would I need their help?
- planet-and-halo 5y ago
  A guy at my job is a gamer and describes it as "buffing the group." Just as in a game, the healer could be the team MVP, but if you measure DPS you are never going to realize it.
  - hashkb 5y ago
    The healers are usually the best players. They'd be better at DPS but everyone wants to be DPS and demands heals constantly. Source: was a priest in WoW back in the day. Because nobody else wanted to, not because my warlock sucked.
- hashkb 5y ago
  Not what I'm saying. I'm saying there are plenty of terrible engineers coasting and this will catch them. Edit: I've been top of regular productivity charts AND the unanimous answer to "who do you go to to get unstuck?" at at least one company you've heard of. Management regularly promoted the suck ups. Read something like Blind and you'll know how prevalent this is.
  - MathYouF 5y ago
    Well I take your point and trust that you are productive and well respected by your peers. I guess you mentioning that the flip side of the false negatives is the true negatives (people with low performance metrics who haven't been fired yet due to kissing up) is a correct response. Sorry for the misunderstanding. I thought your flip side was an alternative perspective on those who help others get unstuck, not on those caught by the HR performance metrics filter.
    - hashkb 5y ago
      I'm happy to get people unstuck. It's the best for everyone and the company. I hate when a "growth hacker" moves a meaningless metric an insignificant amount and gets a bonus so some middle manager can get up and claim a "win" that makes more work for me and my team but costs the company money.

hncurious 5y ago

Result: git committing, excessively.

ARandomerDude 5y ago
And stop squashing.
- lumost 5y ago
  I work at a company where code activity is reviewed from time to time by individuals who are at least somewhat familiar with the breadth of activity an Engineer does. Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.
908B64B197 5y ago
Reminds me of someone. Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him". Three promotions in 18 months and jumped to a FAANG not long after.
- abledon 5y ago
  sounds like hell, but at the same time, he is a legend.
- geoduck14 5y ago
  If getting a promotion really is as easy as committing lots of lines of code, and you are THE ONLY one to figure it out, then you deserve a promotion

AmericanChopper 5y ago

An old boss of mine used to acknowledge people that had contributed excessively high LoCs at the weekly standup. Typically it used to be an indicator that somebody had completed a large portion of work. Then a new guy started topping the LoC charts every week, and it was discovered that he was reformatting every file he touched to use his preferred indentation scheme. It was a pretty lighthearted thing to begin with, but they stopped mentioning it entirely after that.

combatentropy 5y ago
In 1982 Apple was having programmers report lines of code. Bill Atkinson refactored Quickdraw and put down a negative number, -2000 lines of code. Then they stopped asking him to fill out the form. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

gricardo99 5y ago

Indeed, some SCM metrics could be used to reach exactly the wrong conclusion: lines-of-code add/removed. Oh my gosh! Jonny coder over there has been deleting, deleting! our code. Fire him immediately! Many years ago there was a discussion on HN about that same topic[1] (And since then many more I'm sure). 1 - https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815

opinion-is-bad 5y ago
Simpson’s Paradox takes many forms. If your sampling or measurement criteria are wrong, even subtlety, then the results are nonsense without anyone knowing. Practicing statistics in an area for which you are not an expert is almost always a bad idea.
_tom_ 5y ago
Dilbert is relevant: https://dilbert.com/search_results?terms=Write%20Minivan https://dilbert.com/search_results?terms=Write%20Minivan Metrics are frequently inaccurate and easy to game.
- xsmasher 5y ago
  A decade earlier, this story at Apple https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
croes 5y ago
Maybe that's the reason why programmer using spaces instead of tabs earn more money. They get payed by file size

akg_67 5y ago

LOL, reminded me of my own case. I had the fewest issues closed and longest time to close owned issues. But my boss knew the reasons and was very understanding that I was acting as escalation point for the team. It was the upper management, who was lead by a bean counter CEO, couldn't understand why I was still around with such low productivity. Saving grace was my boss and sales people who kept hearing good things about me from customers.

908B64B197 5y ago
> it was the upper management, who was lead by a bean counter CEO, couldn't understand why I was still around with such low productivity. Career red flag right here.

TeeMassive 5y ago

At a company I used to work the manager of our next money cow project promoted the 2-4 people who committed features the fastest. They were "10 times as fast" as the others and therefore it made sense for him to give them the title of "architects" and give them veto power. Turns out they spewed out the most ugly, over-engineered and unmaintainable code that all the others had to fix/maintain/understand their mess.

blululu 5y ago

Reminds me of a classic story about Bill Atkinson back in the 80's: TLDR; Management was counting lines of code as their metric of productivity. Which was great until someone actually cleaned up the code base and added -2000 lines of code. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

908B64B197 5y ago

Spoken from the man himself https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0

bgro 5y ago

I was the go-to on almost every team at my last job when there was a hotfix, major risk change, security fix, etc. I knew the whole system pretty well and knew how to find and match up our awful logging to actual code and find the flaw far faster than anybody. I'd develop and test a fix and quietly discuss with that team's tech lead about risk vs reward concerns to see if they agree or want to discuss changes, then I'd get a pull request out there. The management / executive team would always hear about major crisis hotfixes, then immediately see my name on the high visibility pull request. Thus, they think I personally must have been the cause of the problem. Somehow I was on every team and responsible for every feature, every hotfix, and the poor work every team developed that irritated clients. (Funny how I was never responsible for the positive things, though.) Then there'd be companywide meeting / email to cover what happened with a screenshot with my name by a hotfix with comments like "Let's not have to do things like this going forward." "Some of us have to actually work for a living, and heh I don't know about you guys but _I_ don't appreciate having to panic review things like THIS!"

pts_ 5y ago
Career management enters the chat. Play blame game nothing gets done.
- mgh2 5y ago
  Management had low understanding of correlation vs. causation. This reminds me of one of Udacity's first classes: do firefighters cause fires? https://www.youtube.com/watch?v=Ku9E9uKyr4E https://www.youtube.com/watch?v=Ku9E9uKyr4E
bonzini 5y ago
Sometimes I have seen the opposite problem, where people look like they do not have enough engagement in customer cases, because most of the bugs are ironed out before the new release is announced.

ssss11 5y ago

Similar to an experience I had in my first job - repairing electronics (pcb’s, components, tuning radios and lasers) for supply chain environments and we were (loosely) reported on via how many jobs were completed per day and the average for a technician was somewhere around 5, so 25 per week. The experienced technicians would leave the base stations though as they took a long time to troubleshoot and repair, so customers would get upset that the turnaround was slow. But these repairs were also profitable because extra labour and parts margin. So I would take them on - win/win I thought - happy customers and billing the expensive jobs, heck someone has to do these jobs. The problem was that you couldn’t complete more than about 1.5 of these jobs per day on average. Anyway, new lab manager comes in, crunches numbers and they decide my work rate is too low and I’m no longer required… I still wonder to this day if it had an impact on turnaround of those devices.. I would like to think they realised what they did. I also learnt not to get too far from the herd even if you have the best of intentions.

pts_ 5y ago

Reminds me of a CEO who proudly thought technically knowledgeable friends are good to get ideas from but not hire.