3 ms·

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 ra

by 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.
    - willcipriano 3y ago
      The people who would be confused by these metrics in the way you describe aren't going to do any better without them.

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.
  - willcipriano 3y ago
    The people who would be confused by these metrics in the way you describe aren't going to do any better without them.