Some older colleagues have told me a few stories on what happened, when some managers thought it was a good idea to couple the performance review goals with quantitative metrics: they straight away created a perverse incentive. If I remember correctly, it was something in the line of "number of fixed bugs". No, nobody deliberately introduced new defects because of it, but it turned out, fixing typos, doing cosmetic adjustments etc.pp. suddenly got much more attention than it would have been necessary, especially in comparison to issues, which would consume the better part of a work week and actually provide much more value.
But morale tales aside: you're not a manager and you like to measure things and gain some insights in your productivity. So for starters, how about this suggestiong: try to measure both the capabilities and the quality of your system at discrete points in time. If between two measurements both got better, or one increased and the other stayed the same: congratulations, you were productive - either by adding features or maintining your systems' health.
Measuring the capabilities is hard. Maybe you have something like stories with story points assigned to it, or maybe you default to lines of code.
Measuring quality is - in my opinion - more promising and interesting.
Quite a few books have been written on it. One that I found particularly interesting, and think that you might find it inspiring for your purposes as well, was "Your code as a crime scene" by Adam Tornhill. The author shows a lot of cool techniques to get quality metrics (e.g. on coupling, churn, stability) for software systems from their version control history. He also has developed a tool called code-maat to do much of the heavy lifting for gathering the data, which you might find useful independent from the book: github.com/adamtornhill/code-maat
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some older colleagues have told me a few stories on what happened, when some managers thought it was a good idea to couple the performance review goals with quantitative metrics: they straight away created a perverse incentive. If I remember correctly, it was something in the line of "number of fixed bugs". No, nobody deliberately introduced new defects because of it, but it turned out, fixing typos, doing cosmetic adjustments etc.pp. suddenly got much more attention than it would have been necessary, especially in comparison to issues, which would consume the better part of a work week and actually provide much more value.
But morale tales aside: you're not a manager and you like to measure things and gain some insights in your productivity. So for starters, how about this suggestiong: try to measure both the capabilities and the quality of your system at discrete points in time. If between two measurements both got better, or one increased and the other stayed the same: congratulations, you were productive - either by adding features or maintining your systems' health.
Measuring the capabilities is hard. Maybe you have something like stories with story points assigned to it, or maybe you default to lines of code.
Measuring quality is - in my opinion - more promising and interesting.
Quite a few books have been written on it. One that I found particularly interesting, and think that you might find it inspiring for your purposes as well, was "Your code as a crime scene" by Adam Tornhill. The author shows a lot of cool techniques to get quality metrics (e.g. on coupling, churn, stability) for software systems from their version control history. He also has developed a tool called code-maat to do much of the heavy lifting for gathering the data, which you might find useful independent from the book: github.com/adamtornhill/code-maat