8 ms·

> others would run screaming from a place with mandatory code reviews. Why would a peer looking over your code be so terrible?

toast0 7y ago
I don't mind occasional code reviews, but I would not want to work somewhere where they're mandatory. In my experience, mandatory code reviews lead to diffusion of responsibility; because everything is reviewed, changers take less care, even when reviewers treat at least some reviews as perfunctory, leading to preventable errors that weren't caught in review (although I've heard code reviews are supposed to catch preventable errors like this). If changers take more individual responsibility in their change, or a review is a special occasion, demanding and receiving a thorough and thoughtful review, the results seem better from what I've seen by observing groups I work in, and others I'm exposed to. Mandatory reviews lead to excess communication, and the delays that cause. Stopping to get a review takes wall clock time, as well as the reviewer's time, and causes interruptions (or if done in batches to preserve reviewer's attention, takes a lot more wall clock time). This really breaks the glorious cycle of fast iteration. In my experience, 60 seconds of results from production is worth more than most review feedback. In case of changes related to production issues, that means any event requiring a change needs two people to respond. Some events may require consensus, but others have clear solutions. OTOH, it really depends on the cost to make changes, and the cost of making mistakes. In an environment where changes are expensive, and making mistakes is expensive, maybe mandatory reviews and extensive testing and actually having a specification make sense. Thankfully for me and the stakeholders involved, I don't work in such an environment.
mypalmike 7y ago
Sometimes code reviews can feel like being a carpenter and having to ask your coworkers their opinions after each nail you drive whether you did it right. And then having to spend time judging your coworkers' nail-driving skills rather than putting up the wall you've been given a deadline to build. I've learned to accept code reviews as worthwhile overall, but there are definitely trade-offs.
Wurdan 7y ago
A lot depends on how the code review is done. Where I'm currently working we have to do code reviews for an external auditing process and the whole thing has become farcical. It's not at all unusual to be asked to review thousands of lines of code that another developer has spent months working on for a part of the system you're totally unfamiliar with. When I started there and asked the lead developer on guidance for what to look out for, he admitted to just looking for potential null references and rogue code seeking to intentionally damage the system.

toast0 7y ago

I don't mind occasional code reviews, but I would not want to work somewhere where they're mandatory. In my experience, mandatory code reviews lead to diffusion of responsibility; because everything is reviewed, changers take less care, even when reviewers treat at least some reviews as perfunctory, leading to preventable errors that weren't caught in review (although I've heard code reviews are supposed to catch preventable errors like this). If changers take more individual responsibility in their change, or a review is a special occasion, demanding and receiving a thorough and thoughtful review, the results seem better from what I've seen by observing groups I work in, and others I'm exposed to. Mandatory reviews lead to excess communication, and the delays that cause. Stopping to get a review takes wall clock time, as well as the reviewer's time, and causes interruptions (or if done in batches to preserve reviewer's attention, takes a lot more wall clock time). This really breaks the glorious cycle of fast iteration. In my experience, 60 seconds of results from production is worth more than most review feedback. In case of changes related to production issues, that means any event requiring a change needs two people to respond. Some events may require consensus, but others have clear solutions. OTOH, it really depends on the cost to make changes, and the cost of making mistakes. In an environment where changes are expensive, and making mistakes is expensive, maybe mandatory reviews and extensive testing and actually having a specification make sense. Thankfully for me and the stakeholders involved, I don't work in such an environment.

mypalmike 7y ago

Sometimes code reviews can feel like being a carpenter and having to ask your coworkers their opinions after each nail you drive whether you did it right. And then having to spend time judging your coworkers' nail-driving skills rather than putting up the wall you've been given a deadline to build. I've learned to accept code reviews as worthwhile overall, but there are definitely trade-offs.

Wurdan 7y ago

A lot depends on how the code review is done. Where I'm currently working we have to do code reviews for an external auditing process and the whole thing has become farcical. It's not at all unusual to be asked to review thousands of lines of code that another developer has spent months working on for a part of the system you're totally unfamiliar with. When I started there and asked the lead developer on guidance for what to look out for, he admitted to just looking for potential null references and rogue code seeking to intentionally damage the system.