3 ms·

> who delivers 1/3rd the features as everyone else, but they offer such effective mentorship that their five teammates deliver features 2x faster? I haven't re

> who delivers 1/3rd the features as everyone else, but they offer such effective mentorship that their five teammates deliver features 2x faster? I haven't really encountered this. Generally speaking people who can teach others to be much more productive like that are unsurprisingly themselves, more productive. This fictional person would be better suited to a people management or coaching role as a individual contractor they only achieve a third of the average.

zachmu 3y ago
Sometimes you get the cranky old guy archetype who doesn't really get much done but is really good at making sure the kids don't make any really dumb mistakes, which is its own kind of value
tanjtanjtanj 3y ago
Every team I've ever worked with (11) has had at least one person that would meet this archetype. Their team-based contribution usually wilts under the kind of individualized metrics being pushed for by some here and the team suffers as a result even if their own metrics get better.
- willcipriano 3y ago
  Then do my second case, this person gets a different title so we can evaluate them differently. Now with the major objection to objective performance review gone we can do that for the actual individual contributors.
  - tanjtanjtanj 3y ago
    I have no need to do that as I'm actually involved in my teams and don't need arbitrary numbers to see that someone is contributing. I'm fortunate that I have been able to avoid (or actively dodge) metric perverts in my career.
skeeter2020 3y ago
this type of person is exactly who we try to identify for staff and higher roles. They could be 20% or even 50% more productive as an individual, but if they raise everyone's game even 2% across 50 or more people they are producing far more value. The reality is they crush fewer tickets individually, and that's a good thing, but it gets perverted by a purely metrics-driven assessment.
- milesvp 3y ago
  My experience is that the best devs should not be crushing tickets. Just like the best surgeons have some of the worst survival rates, because they get the hardest patients, the best engineers should be working on the hardest problems the team faces. They should be spending a lot more time doing research, de-risking and clearing the way so that the rest of the team can crush the tickets.
  - willcipriano 3y ago
    Not just tickets. Lines of code (not just in main but in branches), deployments, runs of the automated build/test suite, lines of documentation written, number of responses in your company technical emergency slack channel, after hours pager incidents resolved, etc, etc If the people near the top of those leader boards are near the top of the comp leaderboard your job is done as that makes sense by the numbers, if not you need a really good justification as to why* if you want to keep those literal top performers for long. *or crossed fingers nobody discusses comp before you exit
    - drewcoo 3y ago
      These things are vanity metrics. > Lines of code (not just in main but in branches) IMO, the best devs can end up with negative LOCs per measurement period. Neophytes will never have negative LOCs. Mediocre devs who copy and paste a lot can have really high LOCs. > lines of documentation written And the more documentation you have the more out of sync it is with reality.
      - 3y ago

zachmu 3y ago

Sometimes you get the cranky old guy archetype who doesn't really get much done but is really good at making sure the kids don't make any really dumb mistakes, which is its own kind of value

tanjtanjtanj 3y ago

Every team I've ever worked with (11) has had at least one person that would meet this archetype. Their team-based contribution usually wilts under the kind of individualized metrics being pushed for by some here and the team suffers as a result even if their own metrics get better.

willcipriano 3y ago
Then do my second case, this person gets a different title so we can evaluate them differently. Now with the major objection to objective performance review gone we can do that for the actual individual contributors.
- tanjtanjtanj 3y ago
  I have no need to do that as I'm actually involved in my teams and don't need arbitrary numbers to see that someone is contributing. I'm fortunate that I have been able to avoid (or actively dodge) metric perverts in my career.

skeeter2020 3y ago

this type of person is exactly who we try to identify for staff and higher roles. They could be 20% or even 50% more productive as an individual, but if they raise everyone's game even 2% across 50 or more people they are producing far more value. The reality is they crush fewer tickets individually, and that's a good thing, but it gets perverted by a purely metrics-driven assessment.

milesvp 3y ago
My experience is that the best devs should not be crushing tickets. Just like the best surgeons have some of the worst survival rates, because they get the hardest patients, the best engineers should be working on the hardest problems the team faces. They should be spending a lot more time doing research, de-risking and clearing the way so that the rest of the team can crush the tickets.
- willcipriano 3y ago
  Not just tickets. Lines of code (not just in main but in branches), deployments, runs of the automated build/test suite, lines of documentation written, number of responses in your company technical emergency slack channel, after hours pager incidents resolved, etc, etc If the people near the top of those leader boards are near the top of the comp leaderboard your job is done as that makes sense by the numbers, if not you need a really good justification as to why* if you want to keep those literal top performers for long. *or crossed fingers nobody discusses comp before you exit
  - drewcoo 3y ago
    These things are vanity metrics. > Lines of code (not just in main but in branches) IMO, the best devs can end up with negative LOCs per measurement period. Neophytes will never have negative LOCs. Mediocre devs who copy and paste a lot can have really high LOCs. > lines of documentation written And the more documentation you have the more out of sync it is with reality.
    - 3y ago