|
|
|
|
|
by shados
1830 days ago
|
|
Its unfortunately pretty common. Measuring perf that way is bullshit. It is, however, still a useful signal. It should never be how the final decision is made, but in orgs where managers have way too many reports (which is a separate problems), it can accelerate things a bit. Eg: look at the team's or orgs LoC/Commits over a long period of time in similar roles (long enough to smooth out outliers). Then if someone is DRASTICALLY underperforming (like, 1/10th of the output), you don't jump to conclusion. You starts looking at the code itself and ask questions about the projects, get opinions from the rest of the team, etc. Stuff you should be doing ANYWAY, but with a little more focus. Based on -those- data points, then you can start making a judgement call. But yeah, any manager who stops at the SLOC or number of commits to make perf decisions is awful. I actually worked with a manager who used number of commits exclusively. He also did not know about squash + merge workflows. So people who squashed would get in trouble and those who didn't would get raises until someone in the team finally figured out which metrics he was actually using. That was so sad... |
|