[poikroequ]

The value of code reviews really depends on the code and the person working on the code. For a team who have spent years working on the same repo, code reviews may not hold much value. But if you have a new guy on the team, or a junior, you'll definitely want to review their code.

Code reviews can also do more than just find bugs. You can point out a better way of doing things. Maybe this SQL could be more efficient. Maybe you can refactor some bit of code to make it more robust. Maybe you should put a logging statement here. This method name is confusing, may I suggest renaming it to xyz?

[dkdbejwi383]

> But if you have a new guy on the team, or a junior, you'll definitely want to review their code.

Reviews _from_ juniors or new team members are also really valuable, as they don't have the history or tribal knowledge that others may have. They'll often spot things that have gone overlooked because "that's how it is".

[gwd]

> For a team who have spent years working on the same repo, code reviews may not hold much value.

I have definitely found bugs [ETA during code review] in code written by very senior developers in code they've been familiar with for over a decade.

[kqr]

I got really curious and I'd like to ask you some follow-up questions on your experience in reviewing and receiving reviews. Do you mind shooting an email to [e-mail]?

[phito]

Code reviews also keep the team up to date with what is changing in the code

[seadan83]

Commonly stated, except I think that statement is wrong. A PR is the thing that has the effect of sending emails to the team, it is the PR that leaves behind a webpage & summary of what has changed. It is the PR that is doing the work there, not the CR. Which implies, you can open and then immediately merge PRs without CR to get that same benefit.

CR does give others a chance to study code, and become familiar with it - but that is different from "keeping up to date."