Turn any signal into insight and action. See how PagerDuty Digital Operations Management Platform integrates machine data and human intelligence to improve visibility and agility across organizations.
Connect insights to real-time action by aligning teams through the shared language of business impact.
Check out the latest products we’ve been working on—including event intelligence, machine learning, response automation, on-call, analytics, operations health management, integrations, and more.
Digital Operations Management arms organizations with the insights needed to turn data into opportunity across every operational use case, from DevOps, ITOps, Security, Support, and beyond.
Over 300 Integrations
Discover DevOps best practices with our library of webinars, whitepapers, reports, and much more.
Learn best practices and get support help with resources from our award-winning support team.
See how PagerDuty works with our live product demo — twice a week, every week.
We've created a maturity model to assist on the journey to digital operations excellence. Take our short assessment to find out where your team falls!
Interactive, simple-to-use API and technical documentation enables users to easily try updates and extend PagerDuty.
Engage with users and PagerDuty experts from our global community of 200k+ users. Become a member, connect, and share insights for success.
Get all your PagerDuty-related questions answered by exploring our in-depth support documentation and community forums.
Have you ever worked on a team where it was a challenge to give constructive feedback or confidently share ideas? At PagerDuty Summit 2018, Patrick...
PagerDuty helps organizations transform their digital operations. Learn more about PagerDuty's mission and what we do.
Meet our experienced and passionate executive team.
We are risk-taking innovators dedicated to delivering amazing products and delighting customers. Join us and do the best work of your career.
With the PagerDuty Foundation, we are committed to doing our part in giving back to the community.
Code reviews are an important part of the modern software lifecycle. Unfortunately, a lot of cycles are burned and morale is damaged because there are few guidelines given to reviewers (and reviewees) on constructive feedback and effective written communication. Below are some tips for a better code review process.
Is it to find bugs? Is it to spread knowledge of the codebase? Is it to find architectural problems? What do code reviews offer your team? If you don’t know the answer to this question, you don’t know how well they’re working.
It’s probably best to have this explicit conversation with your team. It’s OK that teams use them for different things, but it is very important that both the author and reviewer know what the expected outcome of a review is.
Within our team, I expect that I’m sharing code mostly to spread knowledge of changes to codebases, and as a sanity check that I’m doing nothing incredibly stupid. Sometimes I will need expert guidance (for example, in front-end work, or in services that I rarely poke around in). Usually, I try to get this before tagging someone in a PR. When this happens, I think it is best to acknowledge explicitly that you’re expecting that person to be the expert, so that they can take a closer look and perhaps help you with a deploy.
If the answer to, “why you do code reviews” includes, “making sure the code follows a consistent style,” cut it out. It’s difficult to review code that is poorly formatted. And it’s really, really tough to review code for both correctness and style without making multiple passes. It’s also really demoralizing to new engineers on a project to look at their PR and see dozens of style comments. Great automated style tools exist that can automatically style your code and you should use these. On my particular team, we strive to use Scalariform for our Scala stuff and Rubocop for our Ruby projects. Under no circumstances in 2017, should engineers be manually fixing formatting issues.
As a fallback, in cases where automation has not been set up, it’s best for the reviewer to correct the formatting themselves instead of adding comments to the author (this is doubly true when you are reviewing code for your own teammate). Small things can be handled directly in the GitHub UI and we shouldn’t be shy about adding a few pointless commits that’ll be squashed down before merging anyway.
Don’t tell a committer how they’ve done a thing incorrectly in a code review remark. Offer a suggestion, and ask what they think of it. For example, take a look at the comments below:
This clearly feels very negative. The author may feel defensive and start a pointless argument, even if there are few benefits to doing so; or worse, the author may feel like a less valuable contributor, and follow the suggestion blindly. In either case, actual harm is done by comments like this.
The best thing you can do is to offer a suggestion, not as a gatekeeper, but as someone who is trying to learn about the changes to the code (even if you really are a gatekeeper).
Why should you make your comments sound so tentative? Because you are reviewing your peer’s code. You have to invite them to politely explain what’s going on, or to notice that you’ve made a better suggestion. Having no manners in this regard eliminates the possibility of discussion for a significant segment of the population.
Let’s talk about my number one pet peeve in code reviews…
Asking a “why didn’t you” question implies a great many things, none of which are constructive or positive. It assumes that the author of the code has previously considered your suggestion and explicitly chose a different one, which may not be the case. It implies that your alternative is obviously superior (especially in the special case of “why didn’t you just…“), and that you require that the author justify their solution against it. It implies that what may be intended as a mere suggestion is, in fact, the default.
Whenever I am reviewing code and my hubris needs to be checked, I try to offer a suggestion. “How do you feel about…” or “what do you think about…” are good drop-in replacements for this phrase.
It is important to recognize that written communications have a profoundly negative bias. We tend to interpret neutral communications as negative, and positive communications as neutral, which is a source of a lot of consternation in code reviews. To combat this, strive for overt positivity.
Terseness can be interpreted as rude or inconsiderate. In particular, avoid adding a two or three word comment.
My genuine unsupported-by-data opinion is that code quality and correctness are only marginally improved by having a code review by a gatekeeper. It is rare that a reviewer shares the same level of insight as the person who authored the code (well, except in the aforementioned, “review by expert”). A better model is to have code reviews treated as a learning exercise for the reviewer, i.e. to understand the changes to the code and to grow in understanding of the code base. I think this leveling gives their questions and remarks appropriate weight, and allows for a healthier discussion about the larger codebase and how the changes interact with it.
Of course, you don’t have to do any of that to be nicer in your reviews.
For receiving a code review, you should follow the same suggestions in reverse. Recognize that terse comments don’t mean the reviewer thinks less of you. Recognize that “orders” are usually just poorly-phrased suggestions, and an invitation for you to think about the problem a (potentially different) way. Recognize that pretty much everything written comes off more negatively than intended, and give a lot of leeway to your teammates.
It’s easy to imagine that brutal code reviews are a ritual that leads to the best outcomes. In my experience, engineers are a lot more sensitive to criticism than they let on, and they are a lot more willing to be found wrong if they feel like collaborators rather than defendants. Take a few extra minutes to add some kindness to your reviews, and I think you’ll find your reviews are a lot more productive and leave you feeling better at the end of the day.
*This post was originally featured on Cory Chamblin’s personal blog. We thought it would be helpful to our blog readers, so we decided to share it here as well.
Real-Time Operations Management in the Cloud Just Got Easier Cloud infrastructure, by nature, is constantly changing as new instances are spun up and decommissioned, which...
As every business evolves into a digital business, and micro-moments matter more than ever to both revenue and brand equity, the need for effective communications...
600 Townsend St., #200
San Francisco, CA 94103
905 King Street West, Suite 600
Toronto, ON, M6K 3G9, Canada
1416 NW 46th St., St. 301
Seattle, WA 98107
5 Martin Place
1 Fore St,
London EC2Y 9DT
© 2009 - 2019