The point of the article seems to virtue-signal on behalf of code reviewing, and yes there are benefits, but they are primarily for the organization and the author of the code.
The issue is that as you become more senior and wise to the politics of a tech organization, the more you realize that being the one doing code review offers you very little benefit.
The strongest claims the author writes seem to be that:
> Doing code reviews can be enforced by your company’s CI/CD processes
Yeah ok but that's a problem for the author, not me, because they can't get their code in, and
> The reviewer can learn new tricks and idioms of the language used.
Which I doubt if I'm a senior engineer with the org.
More importantly, doing a code review has a tremendous opportunity cost - all the time and brain power you need to comprehend and consider problems for on someone else's code are resources taken away from your own contributions. In modern tech companies, this translates to directly affecting your performance review by lowering your potential impact.
The main solutions I've seen implemented to counter this have been
1) Some quota for code review, which means everyone just looks for the smallest pull requests possible (although also has the positive effect of encouraging authors to write smaller more comprehensible PRs)
2) Some measurement in your performance review for your "mentorship", an approximate score that factors in your code review and is deeply unsatisfying when trying to justify your promotion with
I was thinking perhaps the right answer would be to consider code reviewers "co-authors" during performance review, but that's not exactly fair either. I don't know, I'm not an engineering manager.
Anyway, for me the article reads as an engineering director or higher trying to virtue-signal their way into convincing mid-high level engineers into doing the dirty, unrewarding work.
The benefits such as learning and knowledge-sharing are trivial and don't need to be listed; If the code review process were rewarded properly, everyone would love doing it and this article wouldn't need to have been written.
The issue is that as you become more senior and wise to the politics of a tech organization, the more you realize that being the one doing code review offers you very little benefit.
The strongest claims the author writes seem to be that:
> Doing code reviews can be enforced by your company’s CI/CD processes
Yeah ok but that's a problem for the author, not me, because they can't get their code in, and
> The reviewer can learn new tricks and idioms of the language used.
Which I doubt if I'm a senior engineer with the org.
More importantly, doing a code review has a tremendous opportunity cost - all the time and brain power you need to comprehend and consider problems for on someone else's code are resources taken away from your own contributions. In modern tech companies, this translates to directly affecting your performance review by lowering your potential impact.
The main solutions I've seen implemented to counter this have been
1) Some quota for code review, which means everyone just looks for the smallest pull requests possible (although also has the positive effect of encouraging authors to write smaller more comprehensible PRs)
2) Some measurement in your performance review for your "mentorship", an approximate score that factors in your code review and is deeply unsatisfying when trying to justify your promotion with
I was thinking perhaps the right answer would be to consider code reviewers "co-authors" during performance review, but that's not exactly fair either. I don't know, I'm not an engineering manager.
Anyway, for me the article reads as an engineering director or higher trying to virtue-signal their way into convincing mid-high level engineers into doing the dirty, unrewarding work.
The benefits such as learning and knowledge-sharing are trivial and don't need to be listed; If the code review process were rewarded properly, everyone would love doing it and this article wouldn't need to have been written.