I’m well-known within Frogslayer for conducting rather thorough code reviews. I have been asked to present my approach to reviewing the code in a Pull Request (PR) for some time now, but there’s a deeper issue related to code reviews that needs to be tackled first: the lack of motivation to do them.
Finding another developer who enjoys reviewing code as much as I do seems rare. In my experience, the problem most developers face with doing code reviews is not related to the process but rather a lack of motivation. Our minds tend to come up with excuses to avoid or shortcut tasks we do not want to do, and developers can often fall victim to this mentality when it comes to what they see as the tedious task of reviewing code.
What I’d like to propose is that the first step to improving your code-reviewing skills is to try and get to the point where reviewing code is enjoyable. This starts with identifying the specific aspects of a code review that are most distasteful to you and finding ways of approaching a code review that could make it more enjoyable. Developers are different and draw motivation from various places. Some or even all (but hopefully not!) of the points below may not resonate with you. Even if that is the case, please take this as a prompt to discover the mix of motivations that work best for you.
The Terribly Unmotivating But Nevertheless Included Logical Argument
It is uncommon for a developer to consciously view code reviews as not valuable. As I said above, it’s typically a subtle emotion of dislike that leads developers to avoid them, often resulting in the mindset of “I know I should, but….” As a result, it becomes questionable to use a purely logical approach to convince someone to improve their code reviewing process. Nevertheless, it’s worth reminding ourselves of the purpose of code reviews and why all programming work – beyond that of one-off scripts that are not business critical and that do not need to be maintained – should undergo some sort of code review process.
Preventing Bugs
Starting with the obvious, no developer wants bugs to reach production and cause issues, especially ones with their name attached in git blame; however, no matter how thorough a developer is when programming, something will always slip past. Code reviews have a higher probability of catching oversights that might have been missed because the reviewing developer is unlikely to make the same mental mistakes as the original author.
Readable Code
Although this sounds like another cliché, the reality is that code is written for developers, not computers. While developers should ensure they fully understand code before making changes, it’s the responsibility of the original author of code to make it as intuitive and straightforward as reasonably possible. If other developers don’t understand a piece of code, there is a higher chance of them introducing a bug while modifying it. A code review allows other developers to help test how readable the code is before it’s even merged.
Future Resistant Code
To borrow a different set of technical terms, writing code that is Future Proof is prohibitively expensive; however, creating it in a way that is Future Resistant is only sensible. Essentially, this means that we want to avoid writing code today that boxes us in where likely future features or changes are difficult for us to build.
These changes can often take less development effort (but require more thinking for the design) to requiring only a minimal amount of extra work while making the resulting system much more flexible to future changes. Code reviews offer another set of eyes to identify areas where the code might fall short in this regard.
Engineering
Code Optimization: Distinguishing Between Proactive and Premature
Read postThings That Make Me Never Want To Review Code Again
As developers, we have all experienced situations where reviewing a particular piece of code was the last thing we wanted to do. While I cannot promise that it’s possible to eliminate all the things that cause this feeling, it’s possible to reduce it to an infrequent occurrence by addressing the underlying causes.
Time Pressure
Whether you work for a consultancy or an in-house software development team, it’s not uncommon to be asked to deliver something on a project more quickly and with fewer resources than you had initially planned. In my experience, the first two developer practices to go out the window are automated testing and code reviews. This is primarily due to the perception that they are the most immediately dispensable parts of the development process.
By eliminating the pull request code review due to time pressure, the current development team is incurring an unbounded and unknown technical debt. This issue is often either not understood or consciously acknowledged by both the group(s) causing the time pressure and the development team itself.
Developers need to consciously focus on and accept that they are the expert in the world of software development, and code reviews are an indispensable part of the development process. You cannot skip them any more than airline pilots can skip their pre-flight checks. Not only should you refrain from considering it, but you should never offer foregoing code reviews as a time-saving measure. This applies both to direct offers or, more commonly in my experience, indirect ones made by making commitments that require cutting corners.
When non-technical groups (e.g. management or clients) cause time pressure, it is important to approach the situation by speaking their language. You can explain technical debt as something that must be paid either now or with increased cost in the future. Alternatively, use another economic analogy by describing technical debt as a negative externality on the future of the software system. This is one reason why code reviews are seen as immediately expendable – if you skip them now, future team members (possibly including yourself) will pay for it later.
Promising an unrealistic time frame will harm the project, the development team, and the clients in the long run. Instead of skipping the code review, another option that could be offered to “speed up” development is cutting scope by identifying the most important tasks that need to be focused on. Being flexible while still maintaining a firm stance on issues within your domain of responsibility develops trust with your team and your clients as long as you consistently deliver quality results on the timeline you do promise.
The Never-Ending Code Review
It is fairly common among those who conduct code reviews to look at one and feel overwhelmed. This is usually a sign that the work being done should have been broken up into smaller, more manageable pieces. Dividing work into smaller chunks not only helps the reviewer, but also makes the actual development easier to manage mentally.
On the rare occasions where a large amount of work is truly indivisible, doing team code reviews can be highly beneficial. In these cases, the original author can give the team a brief rundown of the changes before everyone dives in, which helps reviewers more quickly identify the lines on which the changes can be mentally broken down.
Unfamiliarity with a Language/Framework/Project
Every developer has experienced being a beginner in a particular language or framework, making those initial code reviews feel tedious when you’re still uncertain what a lot of things do or mean. Maybe you struggle with imposter syndrome and the constant reminder as you see things you don’t understand in someone else’s code weighs on you.
If this is you, know that you are not alone in that feeling. Speaking for myself, I’ve been there many times and will be there again at some point when I have to explore some other area where I have little experience. When this happens, I consciously remind myself of three things:
- Every developer feels this way at times… I’ve heard them say it (and you’ve now seen me write it).
- No one will think less of me for spending some time to understand what is going on. When I run into another developer who is new to an area that I am knowledgeable in and they take longer to finish something or ask a lot of questions, it never crosses my mind to think less of them.
- The opportunity to see a concrete example of code written by people who are more knowledgeable than me in the domain is invaluable. I got into software development for a reason and finding new and different ways of writing something is one of the fun parts!
Believe it or not, stopping for a minute to consciously remind yourself of these points does help. The more you do it, the easier it gets.
Things That Make Me Love Reviewing Code
The secret to improving your code reviews is simple: you get better at things you practice, and you will practice things you enjoy. I wouldn’t shortcut a code review any more than I would stop my favorite movie halfway through or leave Six Flags after an hour. Our minds are surprisingly malleable in this regard. When you focus on aspects of something you like, over time you will begin liking it more and more while focusing on the negative will have the opposite effect.
It would seem helpful then to list some of the things that I like about reviewing code that you might find enjoyable too. If you can adjust your code review process to amplify the parts you like without compromising the goals of a review, do it.
Direct Co-Worker Interaction
Typically, code reviews are thought to be a developer sitting by themselves focusing solely on the code. While this is certainly the most common way of doing things, there’s nothing saying it has to be this way! Set up an ad-hoc time for you and another developer to get together and talk through code reviews together. Particularly for the larger changes, it can be useful to have the original author walk the team through the changes at a high level before the team discusses things.
A word of warning, though: this can easily turn into a costly time sink if the group is too large or if it turns into one of those ritualistic meetings where most people aren’t paying attention. Additionally, if the original author is presenting their change, there is a risk that they may “corrupt” the reviewers’ thought process by seeding the conversation with their original mistake making the problem more difficult to notice. That being said, when handled properly the collaborative approach to reviewing code can be an effective way of improving the quality and frequency of code reviews.
Learning New Ways to Do Things
Most developers seem to enjoy learning new language features, ways to do things, or tools that they didn’t know about before. After all, it would be pretty miserable working in a field as dynamic as most of the software industry if you didn’t enjoy it.
Reviewing other’s code is a surefire way of discovering different approaches to a problem, especially when operating in a language/framework/specialty where you don’t have a lot of experience. Make note of things you haven’t seen before, and ask your co-worker about them. Have a discussion on the things you didn’t expect. Not only will this help you improve as a developer, it’s also interesting.
Teaching Others New Things
As you progress in your career, you will naturally become more experienced than other developers in a specific area. Teaching others, especially some of the more junior developers, can be a huge source of satisfaction, and there’s no better place to teach than on a concrete, real-world problem.
When providing feedback during your code review, it is not enough to only identify issues and offer solutions. It is crucial to explain and make sure they understand why your suggested approach is better than what they originally wrote. Watching that “lightbulb moment” when it clicks can be immensely satisfying.
Transformation is Oddly Satisfying
Speaking of satisfying, there are thousands upon thousands of videos with millions of views of people power washing sidewalks, mowing overgrown lawns, or cleaning dirty rugs. That may seem odd at first blush, but people have an innate fascination with something dirty being transformed into something clean.
Transforming code can have the same effect. Taking code that was written in a less than ideal way and working with the author to refine it into something that is better designed, with better separation of concerns, and even simply formatted in a more readable way can be very satisfying to the right type of person.
Friendly Competition
If you’re competitive, this one is for you. An old co-worker and I would frequently go back and forth trying to find problems with the other’s code. Not only did it make it a fun challenge whenever I reviewed his code to see how many issues I could find, it also made me pay much more attention when I was writing code myself. After all, it wouldn’t do for him to find a mistake of mine. This was a strictly friendly competition, of course, with only a bit of teasing when one of us found a good one; however, it made reviewing code more of a fun exercise than a development chore. Even now, whether the other developer knows it or not, I’m challenging myself to see how many true problems I can find whenever I review code.
Developers Are Not Robots, Much to Our Own Chagrin
As members of a highly technical discipline, software developers often prioritize the strictly technical aspects of a problem, such as how to improve their team’s code review process. While it may be convenient to ignore the human part of the equation, doing so will cause our efforts to fail. Before addressing the code review process itself, you must make a shift in mindset and recognize that reviewing code doesn’t have to be a dreadful chore – it can be something you look forward to.
