The reviewers could well learn new things by reading through the code, and figure out solutions applicable to their own work. The code submitter is likely to receive feedback on their work, making them aware of possible problems and areas for improvement. It makes everyone betterīy joining forces, everyone can learn and get better. Someone could suggest a smarter solution, a more appropriate design pattern, a way to reduce complexity or to improve performance. In a team where everybody has their own background and strong suits, asking for improvements (because that’s what it’s about) is always a good idea. Let’s make something clear: this is not about standards and code linting (at least not exclusively). For instance, proper keyboard navigation, screen reader accessibility, flexibility for internationalization and friendly, non-JavaScript behavior are often forgotten topics in the front-end world, to name but four. It’s always good to make sure not to forget anything. Even good developers get tunnel vision sometimes.

Having someone double-checking our work never hurts, and limits the risk of unnoticed mistakes. This is probably the most important reason of all. But in practice, there are many reasons why having an established code reviewing process helps. Surely we can ship code without having someone metaphorically standing over our shoulder, watching everything we do. So, why does code reviewing matter? After all, we’re all competent here.

Visual studio code review