which could be really important if that single character was a decimal point that was screwing up sscanf in a european locale :-)

obviously, impact of the fixed bugs should be taken into account. It's pretty easy to measure too, by things like:

* is this bug affecting many customers? * is it affecting just one, but a really important one? * is this bug release-blocking?

etc.

If you try to game it, it will become very obvious.

> Rewrites, infrastructure, code reviewers, mentoring

Infrastructure is a feature in and of itself. Besides, doing things like improving a build system to reduce build times, or streamlining code review workflow has clear measurable impact. Every rewrite must have an observable measurable impact, otherwise it is simply not worth doing. Your mentees' performance is an excellent proxy to measure your quality as a mentor. Again, all of these can be assessed without much hand-waving.

Code reviews shouldn't even count towards your performance. It's just something that you have to do. (though arguably, if you have to do a lot of code reviews, then it's a clear signal that you're a valuable person on the team who knows a lot of detail about the system).

> There are no objective measures of productivity in the majority of cases for tech workers.

I think there clearly are, and I just listed some of them. Sometimes they're hard to boil down to a single number, but in most cases you can easily tell who's doing meaningful work.

Like I said, not always easy to boil down to a concrete number, but you can always find good proxies. Fixed a problem that caused service to trigger alarms in the middle of the night? Saved engineering hours. Wrote a library that several teams use? Saved engineering hours. Even your example, writing documentation, saves engineering hours.

> Someone who isn't fixing a lot of bugs [...]

How would you be able to do any of that if you're not doing meaningful work on the system?