,
22 tweets,
3 min read
Read on Twitter
Let's talk about code reviews (again). I usually encounter two camps when it comes to code reviews: those who think they are necessary and good and those who think they are an unneeded process that slows people down (or a less efficient alternative to pair programming). 1/
I've seen lots of discussion recently about "you need to do X" to build software effectively. Personally, I don't care if you do agile, XP, kanban, TDD, etc. At a certain point, I don't think the tactics matter all that much so long as what you do works for you. 2/
One exception to that is code reviews. I've found that this is a more controversial opinion than I realized. I honestly believe code reviews, when taken seriously, are important to any team for a few reasons. This is a hill I'm willing to die on. 3/
The first is simply code quality. As I've mentioned many times, there is empirical evidence suggesting code reviews help improve software quality. 4/
Here's why pairing isn't a replacement for code reviews: it's super easy to come up with a bad idea together when you're both in the weeds on something. I've done it a lot. There is something to be said about a fresh set of eyes. 5/
Someone recently asked me how to avoid leaking PII to logs. There are tools that might help, but ultimately there's nothing to stop someone from logging out a password, credit card, SSN, etc. 6/
Code reviews are your best line of defense against this, but there is no silver bullet. If someone has other ideas, I'm all ears. 7/
Second, in my experience, code reviews are an effective way to level up teams in a way that scales by fostering a culture of continuous improvement. 8/
You don't get experienced teams by sending them to trainings. You get them by providing short feedback loops. This is the secret to effective teams. 9/
It's hard to quantify, but getting multiple people involved on a piece of code, even just reviewing changes, pays dividends. Over time, it has a compounding interest if you allow that culture to spread within your org. Shared context/understanding becomes a force multiplier. 10/
A more obvious example is using code reviews to scale other functions of product development. Allow people to become approved security reviewers to better scale security and compliance related changes or infrastructure as code reviewers to help scale infra changes. 11/
Allow people to demonstrate competency in an area and then empower them. This is the only sane approach to centers of excellent IMO (I often see CoE's go horribly, horribly wrong). 12/
Third, when done right, code reviews promote a culture which separates self from code. We critique code, not people. Egoless programming is important. 13/
The senior engineer's code is critiqued by the intern and vice versa. No one is exempt. When you embrace this and allow your teams to develop a culture of trust, they won't want to work anywhere else. 14/
Lastly, code reviews are critical for regulatory/compliance purposes. If you think you don't need to worry about compliance because you're not in a regulated industry, you will soon (or you're wildly mistaken). 15/
People have pointed out to me that I seem to conflate code reviews and pull requests. That's because PRs provide a natural point for evidence collection vis a vis compliance. 16/
PRs are a powerful way to streamline change management processes, and code reviews a good way to support separation of duties. Believe me, the alternatives are far worse (change-advisory boards anyone?). 17/
How to avoid rubber-stamping or people not engaging in code reviews? Build it into your org's promotion process! If people rubber stamp or otherwise don't do a good job of reviewing code, don't promote them. Make it part of the promotion criteria. I'm serious. 18/
Keep on pairing or mobbing if it works for you, but IMO these aren't replacements for code reviews. Also, I find different people work differently. I personally need time to sit alone and think when working on a tough problem. I just can't do it when I'm forced to pair. 19/
One tactic I've found to be effective is periodic group code reviews, especially for large/important things. Throw the code up on a TV and go over it with a fine-tooth comb as a group. This is also a super effective way to level people up quickly. 20/
One last point: code reviews are only effective if you pursue them with purpose. If you're just going through the motions, they merely become red tape for getting code merged. They aren't magic, nor is anything else. 21/
That being said, do what works for you. Be thoughtful, be pragmatic, be self-critical, understand the intent and essence behind things rather than the exact procedures, and know when to break the rules. The only process that really matters is one of continuous improvement. 22/
