Comment by expazl | Hacker News Reader

Comment by expazl | Hacker News Reader

Parent Full thread

No, it's not easy to manipulate. You're thinking in linear terms which isn't what lines of code changed is useful as. You can't use it to distinguish which of 4 different productive programmers is most or least productive. However it's extremely easy to distinguish the non-productive programmer in the group of 5. And it's not easy to fake, because as soon as that developer start merging in a ton of bogus or useless edits to push up their numbers then everyone on the team, including the manager will call them on their bullshit.

It's just like shift times for workers in manual labor jobs. You can't tell which of the people who are meeting up 8 hours a day is most productive based on if they where there for 8 hours and 12 minutes or 8 hours and 25 minutes. But you sure as hell can easily see that if someone is showing up 4-5 hours on a nine-to-five job, then something is wrong. And if that person tries to "fake it" but showing up for 8 hours but spends half the time slacking off, but coworkers and managers will call him on the bullshit.

Let me commit node_modules! And automate regular updates. Baam I've got a huge loc count. True, I ha e to argue why I do it and I say for auditing and reliability and maybe win. Once that is through I reformat the code even so slightly (rewrap comments?)

And when I then do actual work in between I lean towards the solution giving me more lines. Longer variable names, more line breaks, ...

There are so many ways to manipulate that, one I know it's a key metric. Sure, it's hard to go from weakest to top contributor that way, but good enough to get away from last spot who is being fired. At least till all play that game. By then the project goes towards a wall.

So yes, for a one off case to identify engineers one should talk to it is a somewhat useful metric, but I would look at more business relevant metrics like amount of closed bugs or similar first (while of course they can be manipulated easily as well ...)

But this is obviously going to caught during code review and seen as an amateur blunder at best.

I block your removal of node_modules from gitignore

It is easy to manipulate.

You just need to create a shitload of bloated bullshit that somehow "works" (at least more or less).

That doesn't make you productive.

Actually that's even counterproductive as it creates technical debt. But by the bogus metric that would be positive.

Creating bloated bullshit has even more value in terms of measured changes than the initial bloat because it also creates the opportunity to fix it up later for even more changes.

If the team verifies PRs, then it should be hard to get most bogus commits merged in the repo though.

Sure, in an ideal world no bugs and not even bad code would slip through review.

I'm still to find the place where this is true in software development.

Not really. One can always keep refactoring and churning things around. Search-replace to rename some long function name into something even longer. If you’ve managed to enforce the 80 char rule, this would likely result in things linted differently. Boom, massive change. No one can object to a good refactor.

Your entire point revolves around the idea of coworkers ratting out and being smart enough to know. Not every place is so cutthroat and pro-employer this is a given.

The idea the manager would call out individuals is laughable too. Most managers barely know how to code themselves. Give it another few decades before your manager looking through commits is a standard, you're more likely to see alert tools be prevalent before that.

it's easier for me to fake then you to check

Reply on news.ycombinator.com