[TimSchumann]

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.

[gricardo99]

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

[_tom_]

Dilbert is relevant: https://dilbert.com/search_results?terms=Write%20Minivan

Metrics are frequently inaccurate and easy to game.

[xsmasher]

A decade earlier, this story at Apple

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

[opinion-is-bad]

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.

[croes]

Maybe that's the reason why programmer using spaces instead of tabs earn more money. They get payed by file size

[ssss11]

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.

[bgro]

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_]

Career management enters the chat. Play blame game nothing gets done.

[mgh2]

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

[bonzini]

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.

[AmericanChopper]

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]

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_Li...

[akg_67]

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]

> 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]

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.

[908B64B197]

Spoken from the man himself

https://www.youtube.com/watch?v=kHI7RTKhlz0

[pts_]

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

[hncurious]

Result: git committing, excessively.

[908B64B197]

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.

[dxf]

>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.

Sorry to hijack your comment, but I would like to say:

There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?"

Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.

[skeeter2020]

It's still a red flag that needs to be explained. Unfortunately most employees will assume they did not leave voluntarily. The OP's reticence to jump is understandable

[sjg007]

“I made a mistake.” Easy. “Not a good fit”.

Nobody expects someone to get married after a couple dates.

[dxf]

But that's my point. It shouldn't be a red flag on the candidate, and shouldn't need to be explained.

[Clewza313]

That's the way it ought to be, but unfortunately that's not the way it is considered by many in reality, so it's rational for a candidate to want to avoid that situation.

[katbyte]

Couple quick departures is alright, but I recently interviewed someone who was like 10 jobs in 8 years…

[aahortwwy]

> 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.

I do this unironically. Mostly for producing unit tests from more sophisticated testing tools. I'm not silly enough to tell my coworkers that's what I'm doing, though.

[geoduck14]

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

[MattGaiser]

Not only that, but other engineers apparently pointed out the gaming and management didn’t care.

[908B64B197]

I think they were just reorganized when it happened? Or the company had been acquired. Anyways, it became the new way to evaluate devs not long after he joined.

[abledon]

sounds like hell, but at the same time, he is a legend.

[mmh0000]

Thankfully, someone has already create a tool [0] for just this scenario!

[0] https://github.com/artiebits/fake-git-history

[2muchcoffeeman]

I’ve worked with a guy who made lots of small commits with the same commit text. You’d look at a pull request with 30 very minor changes possibly in many places with the same message.

[hulitu]

"Bug fixes and performance improvements." Why blame the poor guy when even big companies do this.

[_tom_]

I guess I should stop squashing my commits when I merge!

[distances]

Or rather, create team policy to require squashing. I greatly favor this over a million "fix" commits that may or may not compile when you're bisecting.

[ARandomerDude]

And stop squashing.

[lumost]

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.

[blululu]

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_Li...

[hashkb]

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]

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]

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]

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]

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]

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]

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.