3 ms·

> So just rubberstamp your pr with a nit to score awesome on the first two? If you're saying you can CR your own commits, that's a different problem to discuss

by yodon 4y ago

> So just rubberstamp your pr with a nit to score awesome on the first two? If you're saying you can CR your own commits, that's a different problem to discuss unrelated to the numbers. If you're saying you're coordinating so closely with the other devs on your team that they're picking up your CR's immediately and they're able to legitimately approve them with just a trivial nit, then congrats - you're "gaming" the system in exactly the way it's designed to be "gamed." In general, if devs are talking to each other and aware of what each other is doing, efficiencies are high and latencies are short. If no one is talking to each other, efficiencies are low and latencies are high. Talking to each other and coordinating with each other is a good thing.

dilyevsky 4y ago
So you’re becoming “aware of what each other is doing” by half reading the pr title and going straight to approve button? I think “legitimately “ is doing a lot of lifting here too
- yodon 4y ago
  You seem to presuppose that the people involved in the team conversations about these metrics are stupid or clueless to a point of willfulness or intentionally bad actors. If that's the case, as with the case where you're somehow able to approve your own CR's, you face problems unrelated to the numbers. If those are the kind of problems you face, you need to fix them well before you try to bring in any processes designed to help a well functioning organization function better, including the case you called out where devs are approving code reviews without understanding them.
  - dilyevsky 4y ago
    Never said anything about approving your own prs nor bad actors. It’s just basic human psychology especially when money is involved and if you’re going to pretend it does not exist you got another thing coming
  - a1369209993 4y ago
    Actually, they seem to be presupposing that you're using these metrics as a target to judge employee performance by (in the style of key productivity indicators), rather than as a diagnosic tool to debug your/management's own mistakes/potential improvements in how the team is organized, and then pointing out in what way the former approach - which always fails regardless of which metrics you use due to Goodhart's law - fails with this particular choice of metrics. Edit: granted, sometimes the result of said debugging is that it really is a hardware problem, and with how unstandardized people are, that's actually common enough that you'll likely run into it. But you don't fix (for example) a disk drive that reports writes as complete before they're peristed by stack-ranking drives and trying to pick the ones that lose data less; you fix it either by replacing the faulty drive immediately (assuming you can get working drives), or (more relevantly to dealing with people) by working around it in software. 0: http://en.wikipedia.org/wiki/Goodhart's_law http://en.wikipedia.org/wiki/Goodhart's_law
  - ajchida 4y ago
    If you also measure the defects in production post release, we can co-relate the quality of CR and narrow down the bad actors
    - dilyevsky 4y ago
      Imho if your intent for code review is to find bugs you’re doing it wrong.

by yodon 4y ago

dilyevsky 4y ago

So you’re becoming “aware of what each other is doing” by half reading the pr title and going straight to approve button? I think “legitimately “ is doing a lot of lifting here too

yodon 4y ago
You seem to presuppose that the people involved in the team conversations about these metrics are stupid or clueless to a point of willfulness or intentionally bad actors. If that's the case, as with the case where you're somehow able to approve your own CR's, you face problems unrelated to the numbers. If those are the kind of problems you face, you need to fix them well before you try to bring in any processes designed to help a well functioning organization function better, including the case you called out where devs are approving code reviews without understanding them.
- dilyevsky 4y ago
  Never said anything about approving your own prs nor bad actors. It’s just basic human psychology especially when money is involved and if you’re going to pretend it does not exist you got another thing coming
- a1369209993 4y ago
  Actually, they seem to be presupposing that you're using these metrics as a target to judge employee performance by (in the style of key productivity indicators), rather than as a diagnosic tool to debug your/management's own mistakes/potential improvements in how the team is organized, and then pointing out in what way the former approach - which always fails regardless of which metrics you use due to Goodhart's law - fails with this particular choice of metrics. Edit: granted, sometimes the result of said debugging is that it really is a hardware problem, and with how unstandardized people are, that's actually common enough that you'll likely run into it. But you don't fix (for example) a disk drive that reports writes as complete before they're peristed by stack-ranking drives and trying to pick the ones that lose data less; you fix it either by replacing the faulty drive immediately (assuming you can get working drives), or (more relevantly to dealing with people) by working around it in software. 0: http://en.wikipedia.org/wiki/Goodhart's_law http://en.wikipedia.org/wiki/Goodhart's_law
- ajchida 4y ago
  If you also measure the defects in production post release, we can co-relate the quality of CR and narrow down the bad actors
  - dilyevsky 4y ago
    Imho if your intent for code review is to find bugs you’re doing it wrong.