6 ms·

Who said I'm measuring PR sizes and lines of code? lol To clarify, the tool is not meant to measure "success". In that case, you are absolutely right, it canno

Who said I'm measuring PR sizes and lines of code? lol To clarify, the tool is not meant to measure "success". In that case, you are absolutely right, it cannot be used for that. And I don't think a tool can measure those things. The tool only is only meant to track important producitivty metrics. PerfPerf is here to check that there isn't someone "playing the game" and doing the bare minimum. AND to praise the ones doing more! Example: When someone on a team, always approves PR's without never requesting changes. If that behavior is not standard in the team, it's gonna be flagged if happening for a full month. Example2: Someone on the team, review only 20% of the PRs when requested as reviewer compared to the average of that team that review 60%. that's also gonna be flagged for review. Let me know if that makes sense.

solardev 2y ago
Lines of code is just an example (as are your other metrics). But the thing is that metrics without context drive poor decisions. And lazy managers will often rely on metrics as a poor proxy for actual performance when they don't have the time or skill or empathy to actually get to know their subordinates and their work well enough. It happens all the time already, not just in coding teams but also in marketing, national politics, etc. Evidence driven decision making is wonderful when the evidence is actually meaningful. But the onus is on you to prove that your methodology is sound enough to do so, rather than just providing other poor metrics that are easily gamed by devs and/or misunderstood by managers. Just as a counter-example, in the teams I've been in, typically many people will be asked to review code, but the bulk of the work is done by peers. The senior reviewers will wait until a few others have already requested changes, and then give the final approval with minor changes. Does your tool account for that? I dunno. I'm sure it could, but teams are full of everyday idiosyncrasies like that. A good manager is already aware of that because they take time to understand the team dynamics and each person's duties, strengths, and weaknesses and adjusts accordingly, placing the person before the metric. They are able to look at data when they need to, but also use their soft skills to improve morale and performance in various ways. It is a skill set like any other, and metrics are only a small part of that.

solardev 2y ago

Lines of code is just an example (as are your other metrics). But the thing is that metrics without context drive poor decisions. And lazy managers will often rely on metrics as a poor proxy for actual performance when they don't have the time or skill or empathy to actually get to know their subordinates and their work well enough. It happens all the time already, not just in coding teams but also in marketing, national politics, etc. Evidence driven decision making is wonderful when the evidence is actually meaningful. But the onus is on you to prove that your methodology is sound enough to do so, rather than just providing other poor metrics that are easily gamed by devs and/or misunderstood by managers. Just as a counter-example, in the teams I've been in, typically many people will be asked to review code, but the bulk of the work is done by peers. The senior reviewers will wait until a few others have already requested changes, and then give the final approval with minor changes. Does your tool account for that? I dunno. I'm sure it could, but teams are full of everyday idiosyncrasies like that. A good manager is already aware of that because they take time to understand the team dynamics and each person's duties, strengths, and weaknesses and adjusts accordingly, placing the person before the metric. They are able to look at data when they need to, but also use their soft skills to improve morale and performance in various ways. It is a skill set like any other, and metrics are only a small part of that.