Hacker News new | ask | show | jobs
by oa335 1178 days ago
A favorite “tactic” of some developers Ive seen is to deliver a half baked solution quickly, then a continuous stream of fixes to that solution. An easy recipe for creating merging a lot of PRs.
2 comments

In general (and not just in software), anything that becomes a known productivity metric will rapidly converge towards the mean.

The worst example I have seen is incentivized story points. Bad news: you just ruined your estimation process.

Managers end up trying to put in counter measures and the whole thing becomes a convoluted mess.

Personally, I think PR are a decent metric, but you need an engineering manager to review (and understand) the work that the team is doing (and the team dynamics—who’s doing what).

Basically, the only way to really understand productivity is to be close to the team. This takes time, and it requires hiring the right manager, so a lot of companies opt for off the shelf solutions (Pluralsight, Jellyfish, etc).

Not saying this is good or bad, it’s just what I have observed.

Agree. This is why "measuring" is bad. You want to monitor. To proactively see how things are going on and consider the context around it.
I totally agree. This is why is bad to "measure". When you say measure, everything will look right in the end. But if you say "monitor", at least to me it feels more towards: "I'm proactively looking at my team to see how it goes. I have a way to see when things will start to go wrong. I can also see how productive people are by correlating data. If I just take PRs as an isolated number, it's not relevant. But if I take it, and see that 80% are actually bug fixes, that raises an issue in itself"