Code reviews are an amazing opportunity for teams to help one another grow and maintain a high bar of quality for their code bases overall. Unfortunately this opportunity is often squandered and both giving and receiving these reviews can easily become one of the most frustrating parts of our jobs. Come learn about tactics for improving the process on your team.

1. Amanda Sopkin
@amandasopkin amsopkin@gmail.com #devsum18
Code Reviews

2. Don’t forget to evaluate
this session in the DevSum app!
@amandasopkin

3. Where are we headed?

4. Code review
“A systematic examination of
computer code...intended to find
mistakes overlooked in software
development.”

5. Code reviews:
Many different flavors

6. Improve us as developers
Why do code reviews?

7. Improve us as developers
Decentralize knowledge overall
Why do code reviews?

8. Improve us as developers
Decentralize knowledge
Share responsibility
Why do code reviews?

9. Improve us as developers
Decentralize knowledge
Share responsibility
Improve code base quality
Why do code reviews?

10. Why do code reviews?
Improve us as developers
Decentralize knowledge
Share responsibility
Improve code base quality
Knowledge spreading

11. Costs of a mistake
times less at code review
10 100to

12. “The first code review”
@amandasopkin

13. Should I know
this?
“The first code review”
Despicable
Idiot
Outrageous
WTF
@amandasopkin

14. Code Review Unit TestingIntegration Testing
Levels of defense

15. Levels of defense

16. 55%
Code Review Unit TestingIntegration Testing
Levels of defense
45% 30%
@amandasopkin

17. Race conditions
Memory leaks
Threading issues
Misunderstandings/assumptions
Security problems
What do code reviews catch?

18. What do code reviews catch?

19. Lightweight vs. Formal
Code Reviews

20. Fagan inspection

21. Author (Coder) wrote the code
Reader
Reviewers
Moderator
Fagan inspection

22. Author (Coder)
Reader paraphrases the task
Reviewers
Moderator
Fagan inspection

23. Author (Coder)
Reader
Reviewers review the code
Moderator
Fagan inspection

24. Author (Coder)
Reader
Reviewers
Moderator inspection/coaching
Fagan inspection

25. Lightweight vs. formal

26. Over-the-shoulder
Email pass-around
Pair programming
Tool assisted
Lightweight code review

27. Over-the-shoulder
Email pass-around
Pair programming
Tool assisted
Lightweight code review

28. Over-the-shoulder
Email pass-around
Pair programming
Tool assisted
Lightweight code reviewLightweight

29. Over-the-shoulder
Email pass-around
Pair programming
Tool assisted
Lightweight code review

30. Atlassian Crucible Atlassian's code review tool
Google Gerrit Open source git code review tool
Github Git hosting and pioneer of the "Pull Request"
Facebook Phabricator Open source git/mercurial/svn review tool
Review Board Open source review tool that is SCM/platform neutral
JetBrains Upsource git/mercurial/perforce/svn review tool
Visual Studio Team Services collaborative environment with git
Code review tools

31. Code review tools: VSTS

32. Automated code review tools

33. Automated code review tools

34. Automated code review tools

35. Importance of human code review
“Code Review is the single greatest way of
noticing and killing bugs, increasing overall
understanding, fixing design problems, and
learning from one another.”
-Graydon Hoare

36. 1. Functional
2. Clean and maintainable
3. Optimized
Stages of Code Review

37. Hotbeds of bad feelings

38. Hotbeds of bad dynamics
anger
jealousy
mistrust
confusion
sad
insecurity
shamefear
annoyed
@amandasopkin

39. 5 Dysfunctions of a Team

41. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

42. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

43. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

44. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

45. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

47. Code Review example

48. feature/my-work:
“Fixing a bug in our zoombinator”
@amandasopkin

49. “This isn’t necessary.
The zoombinator has this
functionality built in.”

50. ?
“The zoombinator is
throwing a zoom
exception and I thought
this would fix the issue. I
can take another look if
you think that would be
better.”

51. “It shouldn’t throw that
exception. Are you sure
you tested it correctly?”

52. “I think your solution is good, but I don’t want to butt in,
so I won’t say anything.”

53. ?
@amandasopkin

54. Dysfunctions at play in our
situation

55. Mistrust

56. Fear of Conflict
and
Lack of Commitment

57. Avoidance of Accountability

58. Inattention to Results

59. 5 Counters for the
5 Dysfunctions of a Team

60. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results

61. Absence of Trust -> Build Trust
Fear of Conflict -> Be Honest and Open
Lack of Commitment -> Work as a Team
Avoidance of Accountability -> Be Accountable
Inattention to Results -> Tune in

62. General strategy:
Be empathetic

63. Be empathetic (Project Aristotle)
People were skilled at reading emotions based on nonverbal cues.
If a team member appeared uneasy with a decision, it was likely
noticed and discussed. If someone appeared down, others
showed concern and support. Those conversations are not always
easy, but they’re important. They allow us to be authentic and
engaged.

64. Be Empathetic AND Be Honest

65. Absence of Trust
Build Trust

66. Avoid assumptions

67. Share experiences

68. Follow through

69. Build Trust
Avoid assumptions
Share your experiences with others
Follow through
@amandasopkin

70. Fear conflict
Be Honest and Open

71. Speak like you like each other

72. Speak like you like each other
Make the other person feel safe
The focus is NOT “being right”
Say “What was the reasoning here...” instead of “why”

73. There is usually more than one
way

75. Ask questions, not statements

76. Speak like you like each other
There is usually more than one way to do it
Ask questions, not statements
Be Honest and Open
@amandasopkin

77. Fear of Commitment
Work as a Team

78. Explain things in the review
I am changing this API because
of a bug we discovered in XYZ
steps.

79. After one hour, take a break

80. Do it thoroughly, or not at all!
Initial comments Discussion Resolution Approval

81. Work as a Team
Explain things in the review
After one hour, stop and take a break
Do it thoroughly or not at all
@amandasopkin

82. Avoidance of Accountability
Be Accountable

83. Break things up

84. Communicate early and often

85. Go face to face when necessary

86. Break things up in the review
Communicate with others early and often
Go face to face when necessary
Be accountable
@amandasopkin

87. Inattention to Results
Tune in to the Team

88. Set a tone for the whole team

89. Establish guidelines/goals

90. Adheres to CodeStyle
Proper object oriented design
Sufficient test coverage
Proper naming conventions
Consider a checklist

91. Set a tone for the whole team
Establish guidelines/goals
Consider a checklist
Tune in to the team
@amandasopkin

92. General strategy:
Be empathetic

93. Back to our earlier
situation...

94. feature/my-work:
“Fixing a bug in our zoombinator”

95. Inattention to Results
Tune in to the Team

96. feature/my-work:
“Fixing a bug in our zoombinator to
prevent zoomification by sanitizing the
request.”

97. “This isn’t necessary.
The zoombinator has this
functionality built in.”

98. Fear of Conflict
Be Honest and Open

99. “Did you consider that the
Zoombie class allows us
to filter bad requests?”

100. ?
“The zoombinator is
throwing a zoom
exception and I thought
this would fix the issue. I
can take another look if
you think that would be
better.”

101. Lack of Commitment
Work as a Team

102. ?“The zoombinator is
throwing a zoom
exception. I think this will
fix the issue because it
won’t be caught at
Zoomification.”

103. “It shouldn’t throw that
exception. Are you sure
you tested it correctly?”

104. Absence of Trust
Build Trust

105. “Could you show me how
this exception occurred?”

107. “Ok sounds good. Thanks
for walking me through
it.”

108. “I think your solution is good, but I don’t want to butt in,
so I won’t say anything.”

109. Avoidance of Accountability
Be Accountable

110. “I think this is the right strategy because we noticed the
bug is not getting past the Zoomifier.”

111. Inattention to Results

112. Inattention to Results
Tune in to the Team

113. Inattention to Results

114. ?

116. Conclusion

117. Empathy is Essential
@amandasopkin

118. @amandasopkin

119. Something to say?
@amandasopkin

120. Thank you!
@amandasopkin

121. And….
Last but not least
– don’t forget to evaluate this
session in the DevSum app!
@amandasopkin

122. Something to say?
@amandasopkin

123. ● Icons taken from flaticon.com
● “The 5 Dysfunctions of a Team” by Patrick Lencioni
● “Code Complete” by Steve McConnell
● “Best Kept Secrets of Peer Code Review” by Jason Cohen
● The New York Times
● Medium
Sources

124. More Examples

125. “Why are you using the Z class?”

126. “Could you clean up this validation
provider?”

127. “Could you clean up this validation
provider?”

128. Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results