Broadly agreed. It's taken me a while to adjust to various different code review practices, styles, and environments, but in the end the opinion I've settled o

Broadly agreed. It's taken me a while to adjust to various different code review practices, styles, and environments, but in the end the opinion I've settled on is that no matter how frustrating it might seem to be to wait for review (especially if it takes a long time), it's always better to have at least one person review any change, even seemingly minor ones (with the possible, albeit not-always-simple, exception of reverts/rollbacks). Why? - It reduces the chance that you get into thoughtless fix-merge-fix-merge loops (it can still happen, but knowing that changes may take time for review has an incentive-correction effect) - It shares knowledge about code changes with other people, so that if-and-when (usually when) bugs occur in that part of the codebase in future, you're not the only person somewhat familiar with them - It provides training and learning opportunities for reviewer and reviewee alike; discussions, scenarios and opinions can all be shared and worked through, and can shift behaviours and improve system and process reliability If there's some magical workflow that can allow shipping your own changes without losing any of those benefits, that will be impressive; for now I'm curious to learn more about this approach, although initially skeptical.