3 ms·

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 aut

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.

quickthrower2 3y ago
The best code review is the one you don’t need to do because you and the coder were working together closely all along. The worst is the “surpriaaayze!” 1500 lines of diffs and a 50 character commit message to describe it all. And the coder went on holiday.
progbits 3y ago
> > The reviewer can learn new tricks and idioms of the language used. > > Which I doubt if I'm a senior engineer with the org. Sorry but that sounds like a very small-minded take. I'm in a pretty senior position, doing tons of code reviews as both author and reviewer. And while of course the knowledge mostly flows from me to the junior folks, I still learn from them often. This profession isn't something with linear knowledge progression where you are strictly more senior and better. Everyone has their own experiences and expertise and things to teach you if you are open to it.
richeyryan 3y ago
In my experience, the quality and depth of my code reviews were a main contributing element in my last promotion conversation for a senior+ role. It wasn't even a metric I had to scrounge up but something my manager proactively raised to justify approving the promotion along with other criteria. Other team members reported to him that my feedback helped their growth. However, there is an aspect of being in the right team and company at the right time. If I worked in a team as experienced and knowledgeable as me, my feedback would have less value. I could also easily imagine some managers making the number of reviews an empty metric that had to be tediously gamed, much like green squares on GitHub. Is it more common than not that senior engineers aren't appropriately rewarded for investing time in code review? Probably, most companies are imperfect in one way or another.
hardware2win 3y ago
>Which I doubt if I'm a senior engineer with the org. Unlikely for all SEs.
UncleMeat 3y ago
# of code reviews is a metric I see on a lot of performance evaluations for TLs and senior engineers. As is some feedback from their team about the quality of code reviews. Shifting some coding norm through code reviews such that a better practice becomes the default is seen as a substantial form of impact. Code reviews also have some more intangible benefits. If I am reviewing a substantial portion of the code in my codebase then I am less likely to be completely unaware of some module or design when there is a problem and we are digging in to debug.

quickthrower2 3y ago

The best code review is the one you don’t need to do because you and the coder were working together closely all along. The worst is the “surpriaaayze!” 1500 lines of diffs and a 50 character commit message to describe it all. And the coder went on holiday.

progbits 3y ago

> > The reviewer can learn new tricks and idioms of the language used. > > Which I doubt if I'm a senior engineer with the org. Sorry but that sounds like a very small-minded take. I'm in a pretty senior position, doing tons of code reviews as both author and reviewer. And while of course the knowledge mostly flows from me to the junior folks, I still learn from them often. This profession isn't something with linear knowledge progression where you are strictly more senior and better. Everyone has their own experiences and expertise and things to teach you if you are open to it.

richeyryan 3y ago

In my experience, the quality and depth of my code reviews were a main contributing element in my last promotion conversation for a senior+ role. It wasn't even a metric I had to scrounge up but something my manager proactively raised to justify approving the promotion along with other criteria. Other team members reported to him that my feedback helped their growth. However, there is an aspect of being in the right team and company at the right time. If I worked in a team as experienced and knowledgeable as me, my feedback would have less value. I could also easily imagine some managers making the number of reviews an empty metric that had to be tediously gamed, much like green squares on GitHub. Is it more common than not that senior engineers aren't appropriately rewarded for investing time in code review? Probably, most companies are imperfect in one way or another.

hardware2win 3y ago

>Which I doubt if I'm a senior engineer with the org. Unlikely for all SEs.

UncleMeat 3y ago

# of code reviews is a metric I see on a lot of performance evaluations for TLs and senior engineers. As is some feedback from their team about the quality of code reviews. Shifting some coding norm through code reviews such that a better practice becomes the default is seen as a substantial form of impact. Code reviews also have some more intangible benefits. If I am reviewing a substantial portion of the code in my codebase then I am less likely to be completely unaware of some module or design when there is a problem and we are digging in to debug.