Comment by ivanjermakov

I worked somewhere that actually had a great way to deal with this. It only works in small teams though.

We had a "support rota", i.e. one day a week you'd be essentially excused from doing product delivery.

Instead, you were the dev to deal with big triage, any code reviews, questions about the product, etc.

Any spare time was spent looking for bugs in the backlog to further investigate / squash.

Then when you were done with your support day you were back to sprint work.

This meant there was no ambiguity of who to ask for code review, and limited / eliminated siloing of skills since everyone had to be able to review anyone else's work.

That obviously doesn't scale to large teams, but it worked wonders for a small team.

I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days.

The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.

Bonus points: reviews are not taken seriously in the legitimate sense, but a facade of seriousness consisting of picky complaints is put forth to reinforce hierarchy and gatekeeping