Building an Inclusive Code Review Culture

&quot;If someone has committed many crimes against the style guide in a PR, the reviewer should point them to the style guide...&quot;<p>Everything a computer can do trivially should not be done by humans. There are plenty of tools available to validate code to all the standards you can dream up. And most languages allow you to even automatically fix style errors or even enforce it for compilation (thank you Go).<p>So instead of codifying it in a style guide document, codify it in config files for linting and autoformat tools instead. The defaults of those tools are often fine for what you need and exceptions can as easily be documented in them as well.

Based on my experience with Mozilla&#x27;s mature code review culture, this article is excellent. If I were going to make one suggestion, it would be to emphasize the points that author jelambs makes below: this approach to code review is inseparable from a commitment to deep shared understanding of the code base. It both depends on and supports that understanding. It&#x27;s an investment in quality as embodied in a particular technical approach and body of work. It&#x27;s not cheap, but what it buys you can be very valuable.

Most code reviews I&#x27;ve participated in have devolved into the senior&#x2F;loudest person making sure that people know who they are and what everyone&#x27;s place in the hierarchy is.<p>Even in reviews where the reviewee had some amazing code that was kind of groundbreaking in one area, still have to find something to gripe about because I have 20 years on this kid. This seems to be quite common in science&#x2F;engineering, not just in code reviews.<p>I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn&#x27;t constantly trying to gun for other people&#x27;s jobs to make their linkedin profiles look more impressive. It&#x27;s been a looooong time now, still searching.

How do you all make sure the code review requests get load balanced across the team, as opposed to 2-3 people getting all the PR requests?

How common is it to get unsolicited reviews on your PRs? In my team, I have some colleagues who will routinely pipe up when they see a PR being uploaded by an &quot;outsider&quot; and will write a litany of complaints in order to block progress and establish their dominance. (I should mention that these colleagues work in a branch office, so this is their only way to assert themselves.)

The real problem here are people with bad attitude and poor communication skills. Bullying other people is a punishable offense in real life, and I don&#x27;t see why code reviews should be any different. Have some basic rules regarding communication. Issue a public warning for first-time offenders. Give them the boot if they do it again. There, problem solved.

Neat to see that they started by interviewing a diverse subset of their engineers; that type of user-centric research is invaluable. Moreover, I wonder what of their methodology could be mapped to a live analysis of the code review conversation threads they&#x27;re having via GitHub.<p>More than anything else, though, I&#x27;m curious where teams like this still go to buy those amazing Apple Cinema displays?!

Not focusing on style violations is foolish. Imagine someone submitted an English paper littered with grammatical errors and typos. It would be difficult to find the intended meaning and bigger picture. Style violations are the same, they have to be fixed before a deeper review can even take place.

Good article, but I don&#x27;t understand why the word &#x27;inclusive&#x27; is in the title.