[phyzix5761]

With a robust enough test suite and a team that does TDD and mob programming, code reviews are pretty much obsolete and a waste of time. Everyone's already involved in the coding process as a mob and the tests catch any regressions.

[jjmarr]

There's two purposes to review. One is to enforce ownership, and the other is to provide mentorship.

Even if you don't have ownership, mentoring is still useful.

I get asked for review by teammembers on an area I have expertise in.

Their solution might work but cause problems later. With review, I can knowledge transfer my lived experience so they don't suffer like I did.

The third purpose to review is stylistic nitpicking and formatting as a simulacrum of actual work. This is useless and turns people off from review.

[phyzix5761]

Yes, I agree, but when the whole team is already part of the development process through mob programming there's no one who hasn't seen the code, hasn't provided feedback/mentorship, and hasn't voiced their stylistic concerns by the time the development is done.

[jjmarr]

If your team is 5 people then sure, it's fine.

From my experience in a massive shared repo with unclear ownership...

[rsalus]

100p agree. Most code reviews devolve to nitpicking anyway. I think it's much more valuable for teammates to review the _design_ and _intent_ rather than the explicit artifacts.