Hacker News Reader

Comment by bjohnson225 | Hacker News Reader

I used to work at a company which used GitPrime, a product which tries to use git statistics to create graphs and productivity rankings for management, but of course it lacks any context.

The easiest way to shoot up the ranking was to avoid any work where you'd not be instantly coding. Never fix a bug where you need to spend time tracking down the issue, never take on the more complicated pieces of work, never use your time to help out junior team members. Instead focus on simple work and trivial refactoring. The statistics are vaguely interesting and I never had it used against me, but the old quote applies: "when a measure becomes a target, it ceases to be a good measure."

View on HN

> never use your time to help out junior team members.

Yeah, I'll be honest, if I had this sort of metric forced on me, I would completely ignore everyone, not just junior devs who (quite often) ask for my help on finding the right tool to accomplish a task. I can bang out code all day, that's easy as shit.

But I think I'd quit before I'd sink to that level.

I once saw something similar where a co-worker on a newly formed team wanted to keep design documents in a git repo. Those types of documents can have dozens of small changes, or in this case commits, each day. It was also painful to read and edit. Luckily our manager stopped the practice early before it took root.

Another anecdote, I was once in a tech lead role and spent a lot of time pairing and guiding others on their development work. My commits were low but impact was high. Low commits counted against me during promotion review.

There's a thing now called GitOps, where you manage your infrastructure by tweaking things in a Git repo then Puppet/Ansible/Terraform/Saltstack/whatever runs them automatically. Easy way to get "number of commits" way, way up in a plausible way.

I have a colleague who creates a Jira for every tiny thing that for most people would be just a routine part of their job. He literally spends more time fooling around in Jira than he does actually doing his real job. But he looks great in the stats...

Design docs as text files (eg Markdown) in Git doesn't actually sound so terrible to me. Counting impact by number of commits is obviously dumb.

It added another tool to manage on top of an internal wiki and a few collaborative document editing. Wiki was basically markdown and it had its own version control mechanisms built in.

I love companies that do this!

An acquaintance of mine told me at a networking event his company started using git stats to do performance reviews. And he pretty much anticipated how it would pretty much end mentoring, documentation and deep debugging (don't bother fixing something, rewrite the offending part of the code as much as you can and hope the bug goes away!).

I ended up poaching 5 seniors engineers from that place, and got a referral bonus for each of course.

Good ole Gitprime! The source of so many bad memories. I used to be on a 4 person team and Gitprime was used to stack rank us for every quarterly "performance" review. Woe to the one who ended up ranked at the bottom...

>when a measure becomes a target, it ceases to be a good measure.

I see this get thrown around a lot but it's not really true. If a metric can be gamed then I agree it's a flawed or poor metric, but there are definitely good metrics that make good targets as well.

Concrete example: I used to work in aircraft maintenance putting Search and Rescue aircraft into the sky to go pull people out of lakes or out of crevasses, etc. One of our KPIs/metrics was the number of hours spent in what's called the "Red" state, i.e. you have no serviceable aircraft that can fly if a callout happens, meaning the region is lacking airborne SAR assets.

There isn't really a way to (legally) game this metric. Either your aircraft is serviceable or it's not. The only way you could cheat is to just lie on your statistics and release aircraft for missions that are actually not serviceable, but that's going to bite you in the ass sooner or later, would require a conspiracy of 10+ people to lie on official airworthiness documents, and doing so is a federal crime not to mention a big ethical no-no.

Our monthly target was zero. I.e. we tried to go each month keeping at least one serviceable aircraft at all times. We only hit that target a few times while I was in that job but it was rewarding, and on months where the Red indicator was particularly large I would drill down with senior staff to determine if it was an anomaly or if there was a trend starting, and we'd address it.

And yet it's still a good measure because it's directly measuring what was our primary objective (i.e. can you put aircraft in the sky to carry out rescue missions or can you not?)

That doesn't provide a way of measuring your individual performance only that of the team. Analogous to that for me would be amount of downtime in our system but that's a whole team metric not an individual one.

In most cases the measurements are proxies for your "share" of the job. In these case they are almost always bad. In all my years in tech I've not seen a way of directly measuring what I do.

> That doesn't provide a way of measuring your individual performance only that of the team

Exactly!

Team metrics can be useful. It is important to know if, say, a team is missing deliverables more than another team. Then you can potentially track down _systemic reasons_.

On an individual level? Can't do it, there's not enough context.

On a pure "lines per code" metric, the most important members on my team would have an abysmal metric. But if they didn't do their jobs, the productivity for everyone else would drop enormously.

>That doesn't provide a way of measuring your individual performance only that of the team.

Indeed.

Is there a clause I'm unaware of in the saying I quoted that stipulates a target/metric must be an individual one only?

Reply on news.ycombinator.com