Code review is a process of verifying that code meets a defined set of requirements.
Imma stop you right there, chief. Maybe one of the ten orgs I’ve been in had some defined standard, and it was heavily-regulated safety critical firmware.
PRs are where the least useful people go to grind ideological axes. Give them the smallest amount of power, and they will abuse it.
Try to define some standards and they will throw sand in the gears. One, to keep grinding ideological axes. Two, if they can’t have move goalposts they become glorified linters and that’s no fun.
This doesn’t spend much time on the scenario where it’s not two peers in the review, but like a junior dev and senior dev.
I recently did a code review for someone who is very junior 1 , and after spending like two hours fixing all the syntax errors and low level goblins, I realized I couldn’t see the forest at all. I’d been staring at the “this variable is undefined in this case” trees so much. And then they were getting antsy and management was getting antsy…
1 They’re not actually junior. They’ve been in this role for years. Unfortunately, this org has like no mentorship and no standards, so they haven’t actually learned much in all that time. They’ve just been copy-pasting code until stuff works.
after spending like two hours fixing all the syntax errors
If the code has syntax errors then clearly the tests don’t pass. A minimum requirement to start reviewing a PR should be that the tests all pass.
Hahaha! They don’t write tests. They are unfamiliar with the concept of unit testing.
I had to explain to them the concept of “you import your function and call it with different arguments to make sure it returns what you expect”. It took a couple tries.
Meanwhile, the head of the “quality” team keeps telling me that I should stay in my lane and not tell the developers how to do their work.
