I have a love/hate relationship with peer review. On one hand, it makes the code better, which is ultimately what we should care and strive for.

But no matter how many times I check my work, how carefully I plan, no matter how many automated tools I use, within five minutes of my pull request going up, another programmer will have noticed some blatant error in my code. Sometimes it’s a contradiction to our naming convention, a variable name that no longer makes sense, or a GWT that doesn’t make sense.

I’m only human. It’s very tempting to skip this process and just slap the merge button without seeking feedback, but ultimately, the computer doesn’t care about my feelings. The programmer who has to look at my code six months later doesn’t care about my feelings. The business whose process is depending on my code really doesn’t care about my feelings. The code has to work. The code has to be readable. The business only cares if it works. When you click that add reviewer button, get ready to ditch your pride at the door.

Peer review only works if the team and it’s managers are on board. Prideful programmers who don’t want their code subject to scrutiny will click the merge button without care. Managers and technical leads who can’t see the bigger picture will block attempts to introduce new process that appears to slow things down - or worse yet - pay lip service to the concept but not actually enforce it. Seniors with a dysfunctional personalities will use peer review as an opportunity to bully juniors, to begin with, you’ll have to work around this people. Start with one sympathetic person at work up from there.

The longer a team has been around without peer review, that harder it will be to introduce. A fresh new team where the tech lead enforces peer review from the beginning means it will part of the bedrock culture. Once the team has been around for while, bringing in peer review means that other team culture and processes will need to be adjusted.

Aside from developer personality and culture issues, the main complaint about peer review is usually how long it takes. While I’ve personally found that the time investment pays itself back many times over and ultimately speeds overall development, the velocity of individual tasks will decrease. Depending on management engagement, you may receive a lot of pressure to ditch this “inefficient practice”.

Despite these barriers, effective peer review will deliver almost immediate benefits. Junior programmers will be exposed to more effective coding techniques, and seniors and tech leads can catch the more egregious mistakes and unclear code before it becomes become the kind of entrenched technical debt that haunts the team for months and years afterwards. In addition, individual developers will become more familiar with other parts of the codebase, reducing the silo effect, and avoid duplication.

Before I go, I’d like to note that I refer to the practice as peer review, rather than code review, as having our peers review our code is only part of the process. Ultimately, we would like to get as much of our processes under peer review as possible. Modern development practices are about communication, and any effective communication requires us to be sure that we are understood.

In later posts, I’ll discuss some of the tactics for introducing peer review to a team, and the potential outcomes.