Re:Pull Requests vs. Pair Programming
by legerdemain on Monday October 04, 2021 @02:40AM
(#28743770)
Everywhere I have worked, code "review" was a cargo cult of people mechanically rubber-stamping each other's changes with zero context or consideration. And these weren't particularly dysfunctional companies!
[ Parent
| on HN ]
I worked in a place where it was not like that. And it was dysfunctional.
Instead, people nitpicked to death and tried to one-up each other with findings. There are loooong arguments over completely irrelevant details. There were multiple rounds of review, sometimes changing the code there and back again. People attempted to code into review comments. And the expectations changed every week, there was no stable standard.
It was more about taking control and showing yourself more caring by finding increasingly insignificant things and then insisting on them.
Oops, and I thought civil engineering was messy. Time to switch back to civil engineering, at least it is, more civil than this.
Re:Pull Requests vs. Pair Programming
by legerdemain on Monday October 04, 2021 @04:32AM
(#28744419)
Code reviews are a smell.
"Only children and fools speak in absolutes." -someone, somewhere, I don't remember.
Code reviews can be a good thing or bad thing, depending on what each party brings in and intends to get out of them. Painting them unequivocally as bad is rather silly.
Re:Pull Requests vs. Pair Programming
by TameAntelope on Monday October 04, 2021 @10:02AM
(#28746820)
Not wanting someone to review your code is a bigger smell, IMO.
Re:Pull Requests vs. Pair Programming
by regularfry on Monday October 04, 2021 @08:01AM
(#28745588)
Code reviews are one of the very few software practices that there's good evidence in favour of.
This is not necessarily in conflict with your statement.
I reckon if you have all senior developers, and design considerations are being dealt with / communicated about in other places (e.g. ahead of time, before the code is written). Then this is largely how things should go: a quick once over to try and spot obvious mistakes. I've worked in companies where code review was like this and it worked pretty well.