4 ms·

> Without concrete and public metrics of "merit", But there are such metrics. For example: * "I implemented feature X, which increased CTR by Y% thus increasi

> Without concrete and public metrics of "merit", But there are such metrics. For example: * "I implemented feature X, which increased CTR by Y% thus increasing revenue by Z" * "New compression scheme reduces bandwidth usage by this much, allowing team B to implement their new feature without worrying about badnwidth usage too much" * "Team C, who uses our library, needed urgent help investigating a performance issue. I dove in and found that the interface we were providing them didn't allow the most efficient usage; designed, tested and deployed an alternative, which resulted in team C being satisfied with performance" I could keep going with these examples (I'm paraphrasing these from some actual work my colleagues did). My point is, it's pretty easy to measure merit in earned dollars, shipped features, fixed bugs, saved engineering hours, and resource usage. Those metrics are concrete and public.

Sorreah 9y ago
A bug might be as simple as a single character fix on a printed string, or as complex as performance isn't as good as we expected, so profile and rewrite parts of the entire application to get acceptable performance. Both count as a single unit in your "bugs fixed" metric. Or do we have meetings to play poker and assign points for bugs? Unless you're fixing tens of thousands of bugs I don't think you're going to have a good sample size to judge the output of 2 people based on just how many bugs they've closed. This can also be gamed ie. pick up easier bugs to appear more productive, open bugs for small issues you notice yourself and fix, and this has the byproduct that real work never gets done. Rewrites, infrastructure, code reviewers, mentoring. No earned dollars, no "features" shipped, good luck measuring "saved engineering hours". There are no objective measures of productivity in the majority of cases for tech workers.
- nice_byte 9y ago
  > A bug might be as simple as a single character fix on a printed string, 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.
zimpenfish 9y ago
> saved engineering hours I'm not sure that's "easy to measure" since how do you know how many hours have been saved without doing it the "slow" way first? > earned dollars Someone who isn't fixing a lot of bugs or implementing flashy new features but is providing good mentoring to the team, writing onboarding documentation, helping them understand the large-scale ramifications of their changes, etc., is essentially invisible to "metrics" yet providing a vital role.
- nice_byte 9y ago
  > I'm not sure that's "easy to measure" since how do you know how many hours have been saved without doing it the "slow" way first? 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?

Sorreah 9y ago

A bug might be as simple as a single character fix on a printed string, or as complex as performance isn't as good as we expected, so profile and rewrite parts of the entire application to get acceptable performance. Both count as a single unit in your "bugs fixed" metric. Or do we have meetings to play poker and assign points for bugs? Unless you're fixing tens of thousands of bugs I don't think you're going to have a good sample size to judge the output of 2 people based on just how many bugs they've closed. This can also be gamed ie. pick up easier bugs to appear more productive, open bugs for small issues you notice yourself and fix, and this has the byproduct that real work never gets done. Rewrites, infrastructure, code reviewers, mentoring. No earned dollars, no "features" shipped, good luck measuring "saved engineering hours". There are no objective measures of productivity in the majority of cases for tech workers.

nice_byte 9y ago
> A bug might be as simple as a single character fix on a printed string, 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.

zimpenfish 9y ago

> saved engineering hours I'm not sure that's "easy to measure" since how do you know how many hours have been saved without doing it the "slow" way first? > earned dollars Someone who isn't fixing a lot of bugs or implementing flashy new features but is providing good mentoring to the team, writing onboarding documentation, helping them understand the large-scale ramifications of their changes, etc., is essentially invisible to "metrics" yet providing a vital role.

nice_byte 9y ago
> I'm not sure that's "easy to measure" since how do you know how many hours have been saved without doing it the "slow" way first? 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?