Code Reviews

A common thing that is often observed in code reviews is people taking them personally, which is the worst thing a dev can do. CRs are meant to encourage best practices, catch errors a dev may overlook as their eyes gloss over the changes, and ensure code quality, while also aiding the skill development of the author AND the code reviewer.

Reviewers aren’t trying to judge the author – they just care about the quality and maintainability of the code being checked in and the more code reviews one does, the more patterns they start seeing of things which become problems in the future. Which is why even the most experienced of developers don’t check-in code without a CR.

A lot many devs myself included, and especially those in the senior/principal levels, tend to look at all code reviews in their team/skip-team – to see where they can jump in and help, to learn from others, and to watch out for things that seem innocent and correct at the component level but could become problems in the future or when looking at the bigger picture.