![](https://corporate-assets.lucid.co/co/7c6fd082-22f3-4acf-ac27-a373bf635b6d.png?v=1712437569187)
Cracking the Code Review, Part 2: Tips for Reviewers
Stephen Rollins
Reading time: about 3 min
1. Be timely in handling reviews
Performing a review is time consuming, so it’s understandable why we might prefer to procrastinate and stay focused on our own work for a time. However, the feedback cycle of code reviews can take a long time, and the last thing you want is to be the bottleneck in that process. Delaying a review can make the developer have to do their own context-switching when you do finally point out things to change. If it takes too long, the changes could start to become less and less in sync with the target branch. We’re all busy, but we also owe it to each other to be responsive when giving code reviews. Key habits:- Begin leaving feedback within 24 hours, even if you can’t review everything in one sitting.
- Strive for “Inbox Zero” days when all pull requests have been reviewed.
2. See the code in action
Remember, the computer is a better compiler than your mind will ever be. Let your build tools have a pass over the developer’s code to catch any regressions or tedious errors. If reasonable, check out the code yourself and toy around with it for a bit. Ask the developer what specific features you should be testing and interacting with if you are not familiar with the changes. Key habits:- Ensure builds pass.
- Check out the branch and test locally.
- Ask for in-person demos or reviews for complex pull requests.
![](https://corporate-assets.lucid.co/co/a2428cc3-d7d6-4543-9cf8-6a154ef29af5.jpg?height=853&width=1280)
Always make sure the code works as part of your review. To save time, you can review it on the original developer’s machine so you don’t have to switch branches.
3. Don’t be afraid to hold the developer accountable to quality
Every organization has standards in their code and software. As the reviewer, you are just as responsible as the developer for ensuring that those standards are understood and adhered to. Pay attention to these details and don’t be afraid to point out the tiny errors in the code. Help your fellow developers learn to become familiar with and follow coding guidelines. Consider utilizing automated methods to enforce quality, such as automated code linters. Key habits:- Ensure code is self-documenting and stylistically accurate.
- Pay attention to security concerns.
- Ask the developer to write unit tests.
- Check if the upstream branch has been merged into the development branch recently.
- Encourage the use of helpful debugging statements.
![](https://corporate-assets.lucid.co/co/9a648950-60e7-4b31-897f-c355a9270aaf.jpg?height=852&width=1280)
Become familiar with your company’s quality and style guides so that you can catch common errors in the code you review.
4. Be the reviewer you wish you could have
Remember, you are reviewing code, not developers. Leave critiques and ask for changes, but don’t attack the coder. Be polite and helpful. Be thorough in your reviews and leave good feedback. Strive to be someone whom people look forward to having review their code. Key habits:- Leave helpful feedback in addition to pointing out bugs.
- Ask questions; prompt discussion and thoughtful analysis.
- Don’t rush your reviews.
About Lucid
Lucid Software is a pioneer and leader in visual collaboration dedicated to helping teams build the future. With its products—Lucidchart, Lucidspark, and Lucidscale—teams are supported from ideation to execution and are empowered to align around a shared vision, clarify complexity, and collaborate visually, no matter where they are. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucid.co.