Code Reviews Are Actually Good for You
Have you ever been annoyed by code review when all you want to do is ship new features? I've definitely felt that way, but in this post I'll show you why code review is actually good and how it can up-level you as an engineer!
I'm feeling a bit mirthful this holiday season, so I've decided to write a post that will be incredibly polarizing: either you will totally agree with it, or you will scream and shout and decry my opinion (to that second category of people, trust me, you will re-evaluate as you gain more experience 🤣). The topic today is code reviews: what they are, why they matter, and why I believe you should embrace them if you wish to grow.
What is a code review?
In nearly all tech companies, when you write new code, you don't just immediately merge that into master and ship to production. Rather, there is a review period where you request those on your team, and maybe even an ancillary team, to inspect your code by looking for bugs, providing suggestions on style and business logic, and possibly even helping you "future-proof" your design so that it lives on beyond your initial contribution (and so that others can contribute to it later if they needed to). The exact priorities that each company has for code reviews can vary, but suffice it to say, it's not usually as simple as "the code runs". This code review process applies to interns too by the way. EVERYONE has to get their code reviewed.
The process for reviewing code is also dependent on the company, but a standard process that might be followed is this set of steps (for git version control):
You create a new branch from master and start implementing your feature.
You create a GitHub PR (pull request) for your feature branch, explaining what the feature is for.
You make more commits as you incrementally develop your feature (and continually push those commits to the GitHub PR too).
Once the feature is ready, you add reviewers and request a review.
As your reviewers make comments on your PR, you make subsequent commits on your feature branch (and push those to the PR) and type out responses to their comments on your PR, stating that you have addressed the comment (and how), or that you have further questions.
Once all reviewers have approved the PR, you then merge to master (deploying to production is normally a separate process that happens after this).
Who reviews your code?
Normally people more senior than you on your team will be reviewing your code, but that's not always the case. Sometimes, I have been asked to review code from a person more senior than myself and who likely knows more about the domain than I do. Why would a more senior person ask a junior person to review their code? A few reasons:
The senior engineer wants to teach or show something to the junior engineer through code.
The senior engineer wants a fresh perspective from someone who is not indoctrinated in the company's coding styles to see if his/her code is understandable and/or intuitive.
The senior engineer is requesting other reviewers besides the junior engineer to be primary reviewers of the new code, but wants to make sure the junior engineer feels included in the team.
The senior engineer wants to up-level the junior engineer's code review skills (this is super important because it contributes to scalable team growth: the junior engineer, in turn, will show what he/she has learned to other junior engineers)
In teams with tech leads as managers, the manager may also review your code. This is not as common, since many tech companies have a distinction between an Engineering Manager (EM) and an Individual Contributor (IC), but it's possible for the EM to review your code if he/she is also a Tech Lead (TL).
Note: IC does not imply "no leadership", but rather that the IC does not officially have people reporting to him/her. ICs can still exhibit leadership, especially if they are senior engineers, but they do not have visibility or control into "manager-related" tasks, such as calibration or compensation planning.Why do code reviews matter?
If someone or some people need to review your code every time you build a new feature, wouldn't that be a super annoying and long process that would slow you down? Not necessarily. I'll share a few primary reasons as to why code reviews are important and then I'll show you how, contrary to what you might expect, they don't actually slow you down.
Primary reasons for code review
To make sure that the code does what it's supposed to do. This is more stringent than "does it run", since that could be checked by any build checker, unit tester, or integration test runner that has to compile the code. Rather, this is a check done by humans to make sure that the intended functionality is actually what's being achieved.
To make sure that the code is structured and styled according to expected standards within the company. Style guides vary company to company, but most tech companies have both language-dependent and language-agnostic rules they expect their developers to follow when writing code. A language-dependent rule might be that in C++, do not add the "using namespace std" directive to a .cc file and instead prepend "std::" to any functions, classes, etc. that require the namespace. A language-agnostic rule might be "no code will be shipped without unit tests for new functionality".
To keep the team up to date on what you're implementing. If everyone on the team just submitted new features in a void, without involving other team members in the review of that code, it's doubtful that anyone except the manager (and in some cases, even the manager too) knows what you're doing (because they'd have to keep checking either what commits have been merged to master or JIRA tickets, both of which busy engineers will not automatically check).
Why don't code reviews slow you down?
As I mentioned in the intro to this section, one might expect that a code review process might slow you down in terms of implementing and shipping new features. While that my be true if considered for the development time of one particular feature, that is a very short-sighted perspective to have. Rather, code review yields gains that are not immediately apparent, but those gains will (1) save you time in the long run and (2) will up-level you as an engineer:
In a lot of code reviews performed by more senior engineers, junior engineers will be exposed to newer development paradigms, libraries, or patterns that they likely have never seen before. Adapting to the suggestions from senior engineers regarding use of these new constructs takes time, but it will add more tools into your engineering toolbox which will serve you for years to come.
Code reviews tend to create more cohesion in a team and that cohesion generates a lot of truly novel and innovative solutions to problems. These solutions are collaboratively concocted by like-minded individuals, all working toward a common goal. Not only is this process a learning opportunity, but it's also going to result in much more powerful and resilient code, which is good. More powerful and resilient code can serve as the basis for even more advanced features built on top of that code in the future.
By asking for review of your code, you will be improving your communication and collaboration skills. Code notwithstanding, you still have to clearly describe your ask to your reviewers and provide them with the context they need to perform an effective review of your code. Since this requires use of language, it is absolutely a muscle that you will need to grow to be effective in a team setting, but it a very worthwhile use of your time.
Note regarding senior engineers
As I discussed earlier in this post, senior engineers tend to be the ones who are the principal reviewers of the code written by junior engineers. That means there is a huge responsibility placed on their shoulders not only to advance the team's larger, longer term objectives, but also to guide the younger members of the team.
All too often, it can be easy for senior engineers to become wrapped up in what they need to accomplish and sometimes this is due to no fault of their own. They just have so much to complete that code reviews can get put on the back-burner. And then junior engineers, trusting the senior engineers and maybe feeling a bit shy about reaching out to them, never actually ping them to ask them to look at some new code.
So to the senior engineers: make sure to always make an effort to prioritize code reviews, especially for junior engineers because it will have a multiplicative effect on your team's impact. And if you know you are prone to sometimes forgetting to review code and would like reminders, make sure to relate that to the junior engineers on your team. That will make them feel more welcome and comfortable reaching out to you if you get busy.
To the junior engineers: Assume positive intent and never feel afraid to reach out to those more senior on your team. There's stuff you gotta get done too, just like they do, and if you need their help, then you just gotta ask. This is definitely a muscle to hone, especially because you don't want to annoy your senior engineer mentors, but there is a balance between trying to figure out stuff on your own vs. reaching out when you need help (or if you are just blocked on code review).
The output result of a healthy code review etiquette on a development team is that no one is blocked on code review because that review is prioritized by reviewers.
Why should you care?
Probably by this point, or maybe even somewhere before this point, you were likely thinking:
Yeah, yeah, this guy is just lecturing me about why I should be okay with code reviews. Why should I even care?
If your thoughts are in line with the above thought, I don't blame you. I absolutely felt that way when senior engineers explained the importance of code review. Code review processes were especially annoying in internships when I knew I had only 12 weeks to implement my project and these code reviews felt like such a chore.
But think about it more like this: you want to be the best that you can be, to be a total master at your craft, and code review is providing you with essential, iterative, and personal feedback to help you on your way to mastery. Oh, and by the way, it's doing that for free 😁. Nowhere else will you get that quality of feedback from engineers who are dedicating their time to you.
Your code is an extension of you and is one of the most explicit demonstrations of your brand. So use code review as a tool to improve it and you will be well on your way to being a more senior engineer that others look up to 😃!