Code reviews are an incredibly effective tool for improving the quality of our code
and what they are particularly good at is those kind of hard-to-measure things,
like readability, maintainability, scaleability. But code reviews are also fundamentally a
critique of a person's work, and, if someone's invested in their work, then that critique
is going to feel somewhat personal. I assume that most people are invested in that work
and that that is really a great thing. We're all lucky if we feel that way. So this is
a highly unscientific survey of my Twitter followers where I ask people how often they
experience defensiveness during code reviews. Really, the takeaway message here is just
that almost no-one never experiences defensiveness, so, almost all of us here are familiar with
that feeling of defensiveness when having your code reviewed, and we've almost certainly
witnessed that defensiveness in other people as well. Not all code review comments are
created equal, so I find it helpful to think of them along these two axes. Along the horizontal
axis, I've got low reward to high reward. In other words, what is the importance of
making the comment that you are going to make? On the vertical axis here, I've put low conflict
to high high flicking, or another - conflict, or how defensive might the author feel when
receiving this comment? Up in the top left quadrant, the high-conflict and low-reward
quadrant, these are things like white space, indentation, typos, arbitrary processes - preferences
for two functions to do the same thing. These are things that the author might perceive
as pedantic. I need to say these don't come up in code review at all. You need to adopt
some conventions, you have a style guide, use a linter, run that as part of your automated
build process. Ideally, you won't be talking about these things in code reviews. These
aren't deep questions and not the best platform for these to come up. The bottom half of this
graph, the bottom two quadrants I will not dwell on, what I would characterise as factual,
like the less important end of the spectrum, a rogue debug left in, the wrong behaviour
that's been implemented, and these are low-conflict precisely because they are factorial. There
will not be a lot of defensiveness around these. That means we are left with this high-conflict,
high-reward quadrant. This speaks to the principles in the gaining - maintainability and scaleability
of your code. These are things about which two competent developers are going to disagree.
That's why you're going to expect conflict in this region on - things like design pattern
choices. Is the solution over engineered or just sophisticated enough? What trade-offs
have been made in the name of readability and are these appropriate? And this is where
we need to foster an active collaboration during code review. So, it's useful to understand
and familiarise yourself with the basic archetypal ways of resolving conflict, because these
map on to ways which code reviews can be dysfunctional. If you know somebody who is very reluctant
to engage in the code review process at all, perhaps reluctant to put their code up for
review, or if code reviews are getting approved with absolutely no comment on them, perhaps
code feels more like a formality, you might be witnessing an avoidant or yielding response
to conflict. On the other end of the spectrum, we know that code reviews can become a forum
for competition, so perhaps an opportunity for one person to demonstrate how much smarter
they are than everyone else. Over in the top-right quadrant here, we have the collaborative approach.
That's what we want, right? Conflict really is just disagreement. And could be rating
over disagreement is very productive. We want active participation from all parties. How
do we get people there? Well, some of these yielding and avoidant types might need their
confidence raising, and people on the left side of the graph will need their defensiveness
lowering. Bearing in mind those two basic principles of lowering defensiveness and raising
confidence, as an organisation, we can try and foster a sense of collective ownership,
so like I said, if you're invested in your work, that's a really positive thing. That's
great. We don't want to reduce that feeling, but we can depersonalise that ownership by
making it a collective team ownership. Peer programming is obviously a great strategy
for this. A simpler one is discussing task prior to implementing them. Even if one person
is going to go ahead and sit down and write the code, discussing tasks before they get
to the stage means everyone is collaborating from the get-go. Make sure you don't silo
code bases. Move everyone around so everyone has a feeling of collective ownership and
that code will be more consistent, everybody will be on the same page to begin with. Make
sure everybody engages in code review. Everybody should review, junior developers can review
certain developers' code, and all code should be reviewed, so code re review should not
be about singling people out. As a reviewer, one helpful technique is to think of code
as being graded like a school assignment. If you get a C-grade code, you can bring it
up to a B or a B-plus. Trying to drag a D-grade to an A is like this likely to be a demoralising
experience for the author - painful all round. We have other techniques mentoring pair-programming
training improving people's coding abilities. Being deluged with comments on a code review
will not be an effective training mechanism. The language used can be really helpful, and
there's some very simple tricks you can use. Avoid the word "you". Use "we" instead. You
can rephrase things in terms of "we" or making the code the subject of the comment. Instead
of saying, "Why did you do it this way?" You could ask, "What are the advantages of this
approach?" Say, "We could do this". Ask questions. Instead of making demands of people and instead
of making statements. Firstly, you might be wrong, you might be mistaken, and secondly,
you're just soliciting the been of the author, showing that you actually value their contribution
and it's a collaborative process. Give positive feedback. It is generally very easy to find
something positive to say about code. Maybe there's a cool library you haven't seen before,
a function you hadn't seen before, or it's just readable, really clear, and, at the very
least, if you're struggling to find something, you can always say, "Thank you for your work
on this. This is really getting there. Just a few small comments." As an author, what
can you do? Practising on your own defensive ness one technique you can use is the as-if
technique. It's challenging, an exercise in self-control but it's effective. As yourself
how would you respond to these comments if you were in your best mood that day? Or how
would you respond to those comments if these were comments on someone else's code, you
were not the author? How would you respond to the comments had been phrased more sensitively,
perhaps? Been phrased differently? You can say thank you to your reviewer. This has two
effects: firstly, it's an implementation of the as-if technique, that, if you act grateful,
it might mean you are grateful. Annotate your review first. You can go through and you can
explain yourself. This is going to start any conversation off on a better buoyant of understanding.
It means you can also solicitor feedback for specific questions, so it's generally very
helpful to direct the reviewer to the points in the code that you do think merit the most
discussion. Okay, so this is obviously scratching the surface of this topic. But what I really
want to emphasise is that, firstly, feelings of ownership are to be expected. Anticipate
them; embrace them. Secondly, we can minimise unnecessary conflict been so, conflict, so
think about the comments you're making or if they need to come up in code review or
another forum. Focus on the interesting questions that come up around readability, design patterns,
maintainability, scaleability of code, things about which two developers can reasonably
disagree. Nudge everyone towards collaboration. Bearing in mind the two golden rules: reducing
defensiveness and increasing confidence before I have a blog post out on this. You can find
it on my website. I have a longer form of this talk, also linked from my website, and
from my Twitter as well. Finally, please do come along to my office hour and chat about
this further. Thanks! [Applause].