What Almost Everyone Gets Wrong About Code Review
What Almost Everyone Gets Wrong About Code Review
The primary purpose of code review is NOT to catch bugs
The purpose of code review is to communicate knowledge and culture.
I wish I realized that earlier in my career. The questions, the naming debates, and the memes: these are main outcomes of code review, not a byproduct.
Our last live session about code review led to dozens of people asking for a recording of the content. You can now find the bite-sized session recaps in our mobile apps: download it on Android and iOS. Alex has done some amazing work in the past 2 weeks to improve the apps significantly – let us know what you think!
If your code has a bug, that’s on you for fixing – don’t rely on code review! Reviewers can certainly help improve code quality by suggesting testing strategies or providing context on different parts of the codebase, but their job isn’t to test your code.
One perspective that gave me more confidence as a reviewer is to imagine the codebase as a large elephant, and engineers are only familiar with their section of the elephant. You don’t need to understand the entire elephant during a code review – just share your perspective and ask questions about how things work together. If you’ve worked in a large company like Facebook, you’ll understand how apt the codebase-as-elephant analogy is 😅
What kind of discussion should happen on code review? Ideally it should be on topics that are concrete enough to be debated at the code level, but also more interesting than inconsequential “nitpicks”. Here’s an illustration of that sweet spot:
Here are 3 tactical tips for code review that you can apply right now:
Provide enough context in the diff such that a “zero-knowledge engineer” will have a basic idea of what’s going on. This will help the reviewer, but also pay dividends for (1) future you, (2) new people on the team, and (3) anyone interested in replicating your work.
One diff, one thesis. This was drilled into us through Facebook culture: instead of one massive diff, split it up into smaller testable changes that are easier to review. Doing this takes longer as the code author, but makes testing and review significantly easier.
Practice empathy during review. Give feedback on the code, not the person. One best practice is to end your suggestion with a question mark: “I think this may crash with negative input. Try testing this case and adding it to the test plan?”
I condensed some learnings into a quick YouTube video, but the real goodness is available for free in the mobile apps. For more resources on code review, check out this comprehensive guide that community member Matt Van Itallie put together.
Alex and I are bringing in our first external collaborator for the mobile apps, which we’re really excited about. We want the apps to be the best destination for engineers, full of insights from brilliant, credible people in tech. If you have thoughts on who else we should work with, let us know. Expect an email in a few weeks with more details, plus a rebrand for our apps :)
One last thing: if you’ve messaged me recently, I’ve probably been delayed or unresponsive. My post about my “fake” accent went mega-viral on LinkedIn last week (post), so I received thousands of messages 🤯 If you reach out now, I should be faster at responding! Thanks to everyone for the support.
Community spotlight
Daniel Dawson is an Android engineer at Foursquare in Seattle and was previously a SWE at Citi. Daniel talked about his career evolution and how the main barrier to seniority is not actually technical depth. It’s all the other “stuff” beyond coding that we’re hoping to cover in this community.
What has been most unexpected in terms of growing your engineering career?
Initially I thought just writing lots of code would make me a better programmer, but over time I realized the importance of things like having quality 1:1s with my manager, having a good code review process, and being surrounded by people who will challenge me. Some of these topics are ones I learned about through this community, and they helped me realize it was time to move on from my first position. I’m happy to report my new role has been ticking all the boxes.
What led you to software engineering?
My career as a coffee educator and front of house manager was stagnating and lots of our patrons were different flavors of programmer. I ended up talking to whoever would give me a minute of their time and heard stories of people getting into tech from all sorts of backgrounds. Hearing myself reflected in their stories, I thought, “Why not me?”
How did you discover Tech Career Growth?
I saw Rahul’s YouTube video with Clement (of AlgoExpert) and sent him a request on LinkedIn with a note. He told me to check out this group and here I am.
Are you really popular in the office due to your coffee making skills?
I mostly work from home, but it seems to make my wife happy! Although I’m not sure she would tell me if it was bad 😅
Thanks Daniel for sharing your journey!
