This document discusses establishing ground rules for code reviews to improve team communication and development velocity. It recommends distinguishing between subjective and objective feedback, tagging comments as blocking or non-blocking, and sponsoring a coding standard to provide consistency while allowing team autonomy. These practices helped make review feedback more constructive and reduced friction between authors and reviewers.

1. ©2008–18 New Relic, Inc. All rights reserved
Ground Rules for Code Reviews
Joshua Gerth, Senior Software Engineer, NRDB Team
©2008–18 New Relic, Inc. All rights reserved
Improving Development Velocity and Team Communication

2. ©2008–18 New Relic, Inc. All rights reserved 2
Safe Harbor
This presentation and the information herein (including any information that may be incorporated by reference) is provided for informational
purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc. (“New Relic”) to sell
securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is proprietary to New Relic and
may not be replicated or disclosed without New Relic’s express written permission.
Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a historical fact or
refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is a forward-looking
statement. These forward-looking statements can often be identified as such because the context of the statement will include words such as
“believes,” “anticipates,” “expects” or words of similar import.
Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and are
subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business with New
Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters covered by such
forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to substantial risks,
uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or achievements to differ materially
from those expressed or implied in any forward-looking statement. Further information on factors that could affect such forward-looking statements
is included in the filings New Relic makes with the SEC from time to time. Copies of these documents may be obtained by visiting New Relic’s
Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov.
New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic makes no
warranties, expressed or implied, in this presentation or otherwise, with respect to the information provided.

3. ©2008–18 New Relic, Inc. All rights reserved 3
The Team Had a Problem
?!!??!
??? !!!
!?!
?!?

4. ©2008–18 New Relic, Inc. All rights reserved 4
Collision Points
Reviewer:
The constant should be
on the lefthand side.
Author:
In Java you can’t do an
assignment in a conditional.
Reviewer:
It’s still good practice.
if ( counter == 100 ) {
return “Target reached”;
}
The tone feels patronizing.
Leaves the change request in
an “unknown” state as it’s not
Blocked or Approved.

5. ©2008–18 New Relic, Inc. All rights reserved 5
Collision Points
return offset < TIME_LIMIT &&
getStartTime() <= timestamp;
Reviewer:
"offset >= 0 && offset < TIME_LIMIT"
would be more clear
Author:
Made the change.
Clarity is subjective.
Author feels frustrated.
Reviewer feels unappreciated.
Lose/Lose.

6. ©2008–18 New Relic, Inc. All rights reserved 6
Taking a Step Back
What was going on? Why was it happening?
How can we fix it?
Code Reviews

7. ©2008–18 New Relic, Inc. All rights reserved 7
How Can We Give Effective Feedback?
• Creative writing 101
• ….
• ….
• How to give critical feedback
• ….
• Computer Science 101
• ….
• Data structures
• Algorithm analysis
• ….
Creative Writing Computer Science

8. ©2008–18 New Relic, Inc. All rights reserved 8
Types of Feedback
Finding these issues in a code review is easy.
“Your variable should use camel
case, not snake case”
Subjective Comments
Finding these issues in a code review is rare.
“Your method name is confusing”
“Your curly brace is on the wrong
line"
“You have created an infinite loop”
“You are missing a semicolon”
“Your boolean logic is wrong”
Objective Comments

9. ©2008–18 New Relic, Inc. All rights reserved 9
Mixing Subjective with Objective
Minimizes
difference
of opinions
Causes
frustration and
resentment
Can lead to a
breakdown in team
communication
Disregards
feelings
“My opinion is the correct one”

10. ©2008–18 New Relic, Inc. All rights reserved 10
Establishing Ground Rules
BLOCKING NON-BLOCKINGBLOCKING BLOCKING
Errors that will
cause an issue in
production.
1
Stated goal of the
change aligns with the
actual changes.
2
Changes align with
the team’s coding
standards.
3
Anything they
personally
disagree with.
4
The reviewer should be looking for the following

11. ©2008–18 New Relic, Inc. All rights reserved 11
Adding Tags
Subjective Comments
Blocking:
Objective Comments
Your boolean logic is wrong
You have created an infinite loop
You are missing a semicolon
Blocking:
Blocking:
Non-blocking: Your method name
is confusing
Non-blocking: Your curly brace is on
the wrong line
Non-blocking: Your variable should use
camel case, not snake case

12. ©2008–18 New Relic, Inc. All rights reserved 12
Concerns
1
The author would ignore
non-blocking comments.
The code our team
produced would not appear
uniform.
2

13. ©2008–18 New Relic, Inc. All rights reserved 13
Sponsoring a Coding Standard
Coding Standards must:
Be written in non-subjective language.
Be fully supported by the sponsor.

14. ©2008–18 New Relic, Inc. All rights reserved 14
Impact
Tone of the subjective comments
became more respectful. Provided
more context.
Authors read, and
responded to,
non-blocking comments.
Authors felt less
resentment and reviewers
felt more appreciated.
Review process
took less time.
Onboarding new reviewers was
quick and easy.

15. ©2008–18 New Relic, Inc. All rights reserved 15
Team Autonomy
Only define what reviewers
should be looking for and
how to give feedback.
Ground rules still support team autonomy.
Each team can adopt which ever
style guide they want.

16. ©2008–18 New Relic, Inc. All rights reserved 16

17. Thank You
©2008–18 New Relic, Inc. All rights reserved