[ben_jones]

I think it will always depend on the team. Process X might be a savior to team Y, but completely screw team A even if team A == team Y (javascript truthiness here).

On the flip side I think you can also say the potential downsides of excessive code review are significantly less then the potential downsides of zero code review.

I dunno.

[frandroid]

> the potential downsides of excessive code review

What would those be?

[gurkendoktor]

Large commits getting stuck in review forever, or until they have too many conflicts to be merged cleanly; small commits being over-reviewed for trivial issues because the reviewer wants to prove that they have actually looked at the code.

[aavz]

On the other hand, if you skip code review for major or complicated changes, you end up with large chunks of code that only one person understands.

Sometimes that works out fine, but other times you don't find out until too late that there are major flaws.

[jupp0r]

You can also refuse changes for being too big to review. Creating incentives for small changes seem like a good thing to me, so I don't see where you complaint is.

[gurkendoktor]

As I said, review culture can also create incentives against small commits, because they will often be over-analysed. I've seen this sentiment on the internet, so it can't just be my own anecdata.

https://twitter.com/girayozil/status/306836785739210752

Not to mention trivial commits, like clarifying comments, something which doesn't happen anymore in my current project - nobody can be bothered to go through the review process for that.

I'm not against code reviews, but I prefer casual post-commit reviews for uncontroversial changes.

[ThrustVectoring]

Bikeshedding and nitpicking. People can try to put you down a peg through overly critical review.

[TheGRS]

I'm not sure what ben_jones had in mind, but we've been doing a lot of pairing and mob programming where I work. I really enjoy it and it feels like the code review is basically just being done at all times (the reviewer is sitting right next to you as you write). But others feel like it eliminates some of the advantages of parallelism (i.e. 2 people working on 2 different things). It also slows down the amount of time to complete stories if one developer is less skilled than the other, but that issue should fade with time.

[frandroid]

Pair programming is an extreme version of code reviewing though :)

[golergka]

Imagine your team prototyping game design ideas with average speed of 1-2 days per concept.

[frandroid]

Prototyping ideas is not a core period for code review though...

ETA: If you end up using a prototype, then you clean up the code at the end of the 1-2 days, and request a review at that point. Code reviews are not meant to get in the way of development. They're a post-development step that happens before QA/testing.