4 ms·

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.

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.