4 ms·

> you know those that carry the sprint, spend half their time reviewing Sounds like a good idea, but no one wants to do this. People would rather quit.

by rr808 3y ago

lionkor 3y ago
not sure I'd want those people on my team anyways in that case, as the shared vision should be good code, regardless of who wrote it
- TeMPOraL 3y ago
  It's not about who owns the code. It's about writing code. Your star performers, those "people who put out 2x the amount of solid, testable, well documented code as anyone else", are likely this effective because they like the coding part. Unless they also love reviewing someone else's code, making them spend 50% time on reviews means taking away most of the nice parts of their work. Assuming they're not robots, expect motivation to suffer - and with it, the quality their future output.
nightpool 3y ago
Your experiences are not universal. Just because you hate doing code review doesn't mean everybody does
- wnolens 3y ago
  They'll burn out because that ask for 50% code review time is often 100 + 50% time. In the playoffs you don't tell your star player to stop shooting and pass more. In my experience, software projects are always lead to accomplish a goal that is out of reach unless the stars bust their ass.
  - nightpool 3y ago
    "In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution. If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.
    - wnolens 3y ago
      Know of any companies innovating technology that compensate well without any of these issues? I'd like to apply.
- wiseowise 3y ago
  I hate it, two other top performers in our team hate it too. They might not be universal, but there’s sure lot of them.
  - yowlingcat 3y ago
    Have you considered whether you and your two colleagues are actually the top performers you think you are?
    - wiseowise 3y ago
      Yes. And yes.
      - yowlingcat 3y ago
        If you have that attitude towards code review, then I'm sorry to inform you that the answer is no.
        wiseowise 3y ago
        Whatever you say.
- baq 3y ago
  The problem is that doing a proper code review is actually hard and thankless work. It’s one thing to skim a medium sized change and another to actually go through every line and every condition, consider second order effects, check what’s missing in the change, etc. I’ve seen estimates that it takes 1h to properly review 400 LOC and the reviewer then needs a long break after that time regardless of whether they’re done reviewing or not.
  - briHass 3y ago
    I've argued to management that it's no less than 50% of the time it took to develop. If you're actually reviewing functionality, you need to understand the original ticket, and at least loosely architect it in your mind. Anything less than that is basically just checking code style or egregious errors.
  - nightpool 3y ago
    If your work isn't being adequately acknowledged and appreciated, that's a major culture problem. I've never felt that my code reviews were thankless. In fact, as I've become a more senior developer on the team, I've found that my code reviews or suggestions can sometimes crowd out acknowledgment for more junior members, so I try to redirect praise where appropriate—code reviews are in my mind the most pure expression of pair programming, where you get a collaborative outcome that's better than either the programmer or the reviewer would be able to achieve independently.
docflabby 3y ago
The reviewing isn't problem it's mostly because you have to become that asshole that everyone hates - developers who produce bad code also are the worst at taking feedback...

> you know those that carry the sprint, spend half their time reviewing Sounds like a good idea, but no one wants to do this. People would rather quit.

by rr808 3y ago

> you know those that carry the sprint, spend half their time reviewing Sounds like a good idea, but no one wants to do this. People would rather quit.

lionkor 3y ago

not sure I'd want those people on my team anyways in that case, as the shared vision should be good code, regardless of who wrote it

TeMPOraL 3y ago
It's not about who owns the code. It's about writing code. Your star performers, those "people who put out 2x the amount of solid, testable, well documented code as anyone else", are likely this effective because they like the coding part. Unless they also love reviewing someone else's code, making them spend 50% time on reviews means taking away most of the nice parts of their work. Assuming they're not robots, expect motivation to suffer - and with it, the quality their future output.

nightpool 3y ago

Your experiences are not universal. Just because you hate doing code review doesn't mean everybody does

wnolens 3y ago
They'll burn out because that ask for 50% code review time is often 100 + 50% time. In the playoffs you don't tell your star player to stop shooting and pass more. In my experience, software projects are always lead to accomplish a goal that is out of reach unless the stars bust their ass.
- nightpool 3y ago
  "In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution. If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.
  - wnolens 3y ago
    Know of any companies innovating technology that compensate well without any of these issues? I'd like to apply.
wiseowise 3y ago
I hate it, two other top performers in our team hate it too. They might not be universal, but there’s sure lot of them.
- yowlingcat 3y ago
  Have you considered whether you and your two colleagues are actually the top performers you think you are?
  - wiseowise 3y ago
    Yes. And yes.
    - yowlingcat 3y ago
      If you have that attitude towards code review, then I'm sorry to inform you that the answer is no.
      - wiseowise 3y ago
        Whatever you say.
baq 3y ago
The problem is that doing a proper code review is actually hard and thankless work. It’s one thing to skim a medium sized change and another to actually go through every line and every condition, consider second order effects, check what’s missing in the change, etc. I’ve seen estimates that it takes 1h to properly review 400 LOC and the reviewer then needs a long break after that time regardless of whether they’re done reviewing or not.
- briHass 3y ago
  I've argued to management that it's no less than 50% of the time it took to develop. If you're actually reviewing functionality, you need to understand the original ticket, and at least loosely architect it in your mind. Anything less than that is basically just checking code style or egregious errors.
- nightpool 3y ago
  If your work isn't being adequately acknowledged and appreciated, that's a major culture problem. I've never felt that my code reviews were thankless. In fact, as I've become a more senior developer on the team, I've found that my code reviews or suggestions can sometimes crowd out acknowledgment for more junior members, so I try to redirect praise where appropriate—code reviews are in my mind the most pure expression of pair programming, where you get a collaborative outcome that's better than either the programmer or the reviewer would be able to achieve independently.

docflabby 3y ago

The reviewing isn't problem it's mostly because you have to become that asshole that everyone hates - developers who produce bad code also are the worst at taking feedback...