Most developers see the value in a code review. Developers can identify bugs before they become a bigger problem and ultimately improve each line of code. But if your team lets out a collective groan when they hear the words “code review,” they aren’t alone.
Software consultant Jacob Beningo comically paints what most developers feel in the tech publication Embedded: “Unfortunately, most developers would rather have a root [canal] than attend a code review. They are often painful and feel unproductive.”
Developers need to meet together and review their code to ensure it’s up to par, prevent avoidable bugs, and improve products. But isn’t there a way to make them more effective? And is it so much to ask for code reviews to be enjoyable?
Improvement starts with one thing: communication.
If you can implement the right tool and strategy that fosters better communication during code reviews, you can improve this essential practice for everyone on your team.
Read on to learn what not to do for code reviews, best practices, and how to use asynchronous communication to upgrade your code review process.
Why is it so important to prioritize great code review processes?
Code review processes and tools help developers create better products, but they also facilitate team alignment, including how your team communicates goals and tests coverage metrics and code coverage calculations to evaluate source code health.
When teams use tools like Loom to provide in-context POV reviews with video, they can peer review code with clarity so there’s no misunderstanding changes or improvements.
In the video below, the engineering manager at Loom, Avanika Krishnaswamy, shows what a code review looks like using video messaging:
Every team wants a productive, positive, and straightforward way to verify and communicate the context for a piece of code. Communication also helps bridge contextual gaps between code reviewers and the author-engineer through clear documentation.
You can improve your code review process by first adopting a few proven guidelines. Then, you can choose a video tool to facilitate better communication and context.
Code review checklist: What not to do
It’s easy to fall into the common traps of poor code reviews. Most leaders want the same thing: a high-quality, finished product delivered quickly. But rushing through this step can also incentivize unhealthy habits and practices that go unnoticed. Below are a few code review tactics to avoid.
1. Editing way too many lines of code per hour
According to Slack, employees who work after hours report 20% lower productivity, 2x greater burnout, and 2.1x work-related stress. Those are all detrimental to an effective code review.
One great way to take a sprint-like approach is to break up reviews and feedback into chapters—no more than a few hundred lines of code per session/hour. Segmented, personalized, and relevant video messages made with Loom can help engineers tackle one issue or project at a time.
Software engineers can work task-by-task based on these focused messages and balance their energy for high performance.
2. Not providing constructive feedback to actually improve the code
If engineers provide little feedback or vague criticism in their follow-up, it won’t promote improvement or uphold your coding quality standards.
Instead, engineers can give specific, actionable steps with context during project quality comments, code style feedback, or review nits. For example, if a reviewer has a hard time reading disorganized code, instead of saying, “I can’t read this. Fix it so it looks better,” they can say, “Can you separate components so it’s easier to understand each line and so we can neatly reuse the code for future projects”?
You can clarify your thought processes by using tools like Loom to display the exact piece of code, explain your ideas, and add additional resources like resource links or a call to action (CTA) step.
3. Failing to praise good code
No one likes to hear criticism. Each engineer on your team is there because they are talented and provide value. And they’re all human and need encouragement. Even if the engineer needs to make improvements or fix errors, you can take the “compliment sandwich” approach. Say something good about the project, then describe what needs improvement. Reinforce your appreciation for the work done, and share your openness to collaboration and ideas.
This healthy leadership approach creates an authentic and positive environment for feedback. It’s also effective for training and mentoring new employees, including junior engineers.
How to perform an improved code review: 5 best practices
Before implementing a video communication tool that streamlines engineering reviews and code maintainability, you can evolve your development process with a few foundational techniques.
1. Establish clear objectives, guidelines, and code review checklists
Software development teams benefit from communication that empowers them to improve code for a shared vision and outcome.
Consider incorporating a code review checklist, which keeps your process, parameters and goals front and center, and can include categories like:
Functionality: Is the code working and performing as the author intended?
Organization: Can you clarify the code so that it’s easier to maintain and understand later on?
Efficiency: Is the code written for the best optimization?
Documentation: Did the engineer include clear commentary, notes, and descriptions for complex portions?
Reviewers should also use metrics to help define areas for improvement, such as:
Defect density: Use this metric to determine the number of errors or defects per total line of code.
Inspection rate: Measure the speed of inspections by dividing the lines of code with the time it takes to analyze the work.
Defect repair time: You can measure the turnaround time for engineers to address and correct comments and defects during the process.
Sometimes, even when your team is actively working to deliver code that meets that shared vision, the review process can get lost in email threads, chats, and live meetings that not everyone can attend.
Maintain team alignment with communication solutions like video messaging, which supports various kinds of engagement.
Rather than writing a tedious email and trying to articulate exactly when your recommendations should be applied, engineers can use screen recording tools like Loom to show the code rather than simply describe it.
Developers can even capture app behavior in real time and demonstrate the impacts of problematic or resolved code behavior. Fellow reviewers or editors can leave comments at exact moments in each video, or reply with a video of their own, perhaps to ask clarifying questions or highlight implemented feedback.
Everyone can be on the same page and correct course before poor-quality code reaches your customers.
You can design a process with clear, constructive parameters and create a healthy review process for your whole team. Engineers can provide context for code readability, and editors can clarify additional ideas and suggestions, such as improvements to remove a bottleneck, address a possible bug, or improve security.
2. Give constructive feedback
Peer code reviews aren’t inquisitions.
In other words, peer reviewers aren’t meant to attack coders or give strong opinions about a job. Their feedback should be clear, respectful, and actionable.
If you teach or train an engineer to build code or document their process a certain way, provide practical feedback so it sticks.
But if you want reviews to be effective, they need to be specific and actionable. The following example by Graphit software engineer Greg Foster showcases the difference between a bad comment and good one.
What bad code review comments look like:
This comment seems aggressive and lacks any specific direction. It could even prevent collaboration by seeding confusion and possible offense to the author.
Instead, a reviewer can provide a more constructive and detailed comment.
What good code review comments look like:
A comment like this offers a detailed suggestion and the context behind the reasoning to help with the specific code and inform future builds.
You can streamline similar feedback with these steps:
Compliment the engineer: Draw direct connections between your praise and the pieces of code or approaches to the project that you appreciate.
Reference areas for improvement: Include your thought process in the context of your recommendations and use cases or examples of how this change, or lack of change, can impact the project.
State action steps: Identify specific ways to improve the code and keep the team on track, on time, and aligned with the vision for the project.
Reemphasize the engineer’s value to the project: Conclude on a positive note that empowers your engineer to grow and evolve the code.
A unified approach to each code review is also valuable. When your reviewers know how granularly or how broadly they should approach a pull request, they can balance efficiency with tendencies to nitpick, which can put the code author on the defensive. Bloomberg engineer Shifalika Kanwar provides another helpful tip for this: Instead of saying “you” to the engineer author, say “we” to soften criticism and add a team component to the work.
This approach to code reviews sustains morale while adding clarity, allowing your team to accomplish projects on time and receive the crucial feedback they need.
3. Promote a growth mindset
Why do companies perform code reviews? To ship better code, to save money and resources that might otherwise be spent on avoidable mistakes and vulnerabilities, and to accelerate the collaboration process.
Your team leadership can encourage a growth-based mindset that fosters engineer competence and confidence. Ask yourself the following questions:
How can your teams provide clearer, faster code reviews?
How can each engineer improve and deliver more value over a certain period of time?
How can your teams collaborate more effectively to streamline their day-to-day workflows?
Applying actionable steps to answer these growth-minded questions will boost code review performance so you can add new features and improve your product.
Even small tweaks can make a powerful difference. For example, your team can use async Loom videos to provide POV context to their code review process and address each relevant line at a time.
Whether onsite, hybrid, or remote, your engineers can process reviewer feedback when it’s most convenient for them and easily capture the necessary context to apply to their own daily tasks. They can then focus more on coding and ship higher-quality code faster.
Remote teams can even use Loom for remote pair programming, collaborating via video messages to build code regardless of timezone or location.
4. Encourage sharing ideas and make reviews easy
Between building products, managing client relationships, and juggling different responsibilities in a business, it’s easy for some team members to feel left out. Getting a word in on how something can be improved can be hard, especially when there’s no defined process.
Code reviews offer engineers a great way to voice ideas, suggestions, and creative feedback to improve functionality and build better products.
The best way to facilitate and encourage input is to use a code review tool that makes it fast and easy. For example, Loom is a convenient way for engineers to provide feedback in their own words. They can provide crucial context about specific pieces of code within a screen share video recording. Viewers can easily engage and respond through comments or their own video replies.
5. Implement a process for fixing code after review
Feedback from your team’s coding reviews should be clear in its intent and desired outcome. With a solution like Loom, you can identify specific action steps and articulate the plan for immediate code changes after reviews.
Engineers can record a Loom video to point out suggestions and concerns. Then, the author-engineer can respond through a video reply or comments on the original video page. The team can continue to engage in real-time to innovate ideas and solutions for better code.
Loom even integrates with project management tools like Jira. This means your engineers can track progress and assign specific action steps in workflows they already use—like when to conduct a code review or meet deadlines for implementing feedback.
Your code reviewers can clearly communicate a call to action (CTA) and maintain alignment on the roles, responsibilities, and expectations for the project.
Adding these collaboration tools helps streamline the code editing process.
Using your tech stack to make code reviews better
By now, you’ve heard why communication tools make code analysis much easier and more effective. In an interview with Loom, Clio Websites founder Nat Miletic explained how critical these code analysis tools are for his team’s high-quality code:
”Our team of international engineers uses videos daily for developer collaboration, client feedback, and training, and we couldn’t live without them.
“By integrating feedback early and often, we enhance individual and team skills and streamline development.
“We use Loom to speed up our code reviews when we record a quick session for features we are working on and explain things in more detail. Recorded videos are more productive than writing to describe complex ideas and coding challenges.”
All of these benefits are grounded in communication. Video communication tools provide modern ways to collaborate during code reviews, track necessary changes, and develop better products.
Record your code review with Loom
With the high performance expected of engineers in various onsite, hybrid, or distributed environments, they need a solution to communicate or conduct pair programming effectively anytime, anywhere, on any device.
Loom’s async messaging makes recording videos fast, easy, and convenient for your engineers.
Reviewers can quickly click “record” on their Chrome browser extension, desktop, or mobile device and share their ideas. This includes sharing their screen and webcam simultaneously—a huge advantage for visually reviewing code.
Engineers easily record videos in a low-pressure environment. Loom is a casual recording platform where presenters can record as if they’re having a natural conversation. If your engineers make a mistake, they can use Live Rewind and simply re-record that section. No need to start over.
Loom’s AI add-on helps your code review team spend less time writing content or editing review videos and more time building valuable code. It automatically removes filler words and composes titles and messages so engineers can quickly share the videos. For example, after you record a video, Loom AI generates the title, invite message, and description of the video for immediate sharing.
Not to mention, integrations like the Loom Chrome Extension in GitHub drive faster feedback cycles with the tools your teams already use.
Record your first Loom code review today for free.
