I'm going to be talking about a study on the perceptions of, and the impacts of, destructive criticism in software code review, and I'm hoping that I can convince you to be more careful about not giving destructive criticism in your code reviews.
So I think you'll all know what software code review is - it's where developers are reviewing other people's source code contributions.
And this tweet illustrates a potentially problematic viewpoint about software code review, and it says that software code review can be honest or nice, pick one, so indicating that you can't have both honest and nice code review.
And the goal of my study was to check if, you know, what really are the perceptions of destructive code review, which is code review that is both inconsiderate and non-specific.
And i wanted to see, you know, if there were different perceptions around these honest - destructive criticism - those that aren't considering the nice parts of code review.
And so to do this we used an online questionnaire - we used vignette style questions.
So basically we developed these hypothetical scenarios and we asked developers - our participants - to look at a code snippet, imagine that they've just submitted this code snippet for review, and that they got some feedback.
And so some of the developers saw constructive version of the feedback and other participants saw destructive version of the feedback, and all of the participants saw two different scenarios, so one with constructive and one with destructive.
And we asked them a series of questions on how they would react to the feedback - how they perceived it - and I'm going to show you some differences between the constructive and the destructive perceptions.
And so here you see these two graphs.
The first at the top is showing reactions perceptions of constructive criticism and the bottom is showing the destructive criticism.
So the first three questions that we asked around the feedback that they received in these hypothetical scenarios was, would this feedback help improve your code, is it valid, and is it appropriate?
And you see at the top - the constructive criticism - the graph is mostly green.
So green indicates the participants are agreeing with these statements.
So at the bottom you see a lot more gold, which is indicating that our participants are disagreeing with these statements.
So participants see destructive criticism particularly as less appropriate.
They did agree that it was mostly valid criticism but that it wouldn't help them improve their code.
They were disagreeing that it would improve their code even though the feedback is valid because it's presented in an inappropriate manner.
We also asked them how motivated they would be to continue working.
And so here you see at the top we've got again constructive and at the bottom destructive.
And we see that overwhelmingly our participants are motivated to continue working on the task with the developer and on the project after receiving constructive criticism.
On the other hand for destructive criticism we see that participants report being much less motivated to continue working, particularly for the developer, but even on the task and on the project as a whole.
So if you have this culture of destructive criticism, what we learned from these two slides that I just showed, you know, people are less likely to improve their code, even if they're getting good critiques of the code, if it's not presented in the right way.
They're less likely to actually improve the code and they're also less likely to stay and continue working on the project.
So we've shown that destructive criticism doesn't have the best impact on your team.
We also looked at demographic differences so we asked participants some demographic questions and we saw some differences.
So particularly women, they perceived destructive criticism - less motivated to continue working particularly with the developer, but also on the project after receiving destructive criticism.
I think this finding is particularly important because we know that women are less than 25 percent in big tech companies, and so this could have implications on retention of women if you have a culture of destructive criticism on your team.
Another interesting difference that we saw is, less experienced developers were less likely to call out this bad behavior.
So we asked the participants to also, you know, write a response - if you were to to write something in response to the feedback that you were given, what would you write?
We saw that our more experienced developers were more likely to say, you know, this feedback is not appropriate, it should be written in a more considerate manner, whereas our less experienced developers were actually more likely to apologize for writing the bad code and to agree with the feedback even when it was destructive.
So again this can have important implications for retention on your teams.
Okay, we also asked about the frequency of destructive criticism.
We asked participants how often they gave destructive criticism and also how often they received it.
And you can see that our participants reported to receive much more destructive criticism than they reported to give.
So 22 percent of participants said that they received some inconsiderate feedback in the last year, whereas only one of our participants or one percent said that they gave destructive criticism - inconsiderate destructive criticism.
Now this can be for a variety of reasons, but one of them could be that people just don't know when they're giving destructive criticism.
So we need more awareness mechanisms to know how our feedback is being received by the recipient.
And finally we asked about general opinions of destructive criticism, and this one's interesting because we see some differences here.
So the first two questions ask, destructive criticism is harmful and destructive criticism will cause a negative reaction for this recipient, and these are lines A and B on the chart.
And you see that overwhelmingly the participants agree with these statements: destructive criticism is not great, right, when you ask it generically, but then when you ask a slightly more nuanced question - so question C says, when receiving code review comments I don't mind getting inconsiderate feedback as long as the feedback helps to improve the code quality.
And here we see a much bigger difference.
So there's a good number of people that are disagreeing with this statement but still a significant number of participants that agree with this statement: they're happy to be abused and get inconsiderate feedback as long as it's going to improve the code base.
We saw quite similar comments in our open-ended responses.
So we asked some open-ended questions about opinions as well, and we saw some comments to these questions along the lines of, like, I don't mind getting inconsiderate feedback, I just prefer direct wording and easier to parse feedback, whereas other participants said things like, it always needs to be constructive, you really need to have considerate feedback every time you give feedback.
And so what are the big implications that I'd like you to take out of this is how you treat people matters.
So if you have a culture of destructive criticism people are less likely to improve the code and they're less likely to stay on your project, so your code quality will suffer.
I also think you need to have pathways for feedback.
So we saw that much less people reported giving inconsiderate feedback, so we might need ways to help people understand when they are giving inconsiderate feedback so that they can improve in how they give their feedback.
I also think that there's not a one-size-fits-all approach to code review.
So you saw that there were differences in opinions in how destructive criticism can be accepted, and some people prefer direct feedback whereas others would rather have feedback that helps them learn.
So considering the needs of the person that you're giving the feedback to is also really important.
And finally you have to be careful with what is made public: some of the comments - the open-ended comments - also pointed that destructive criticism is particularly harmful when it's being made in a public venue, so considering the type of feedback that you're giving and whether it really is appropriate to be transparently shared across the entire team or if it needs to be discussed in private with the person that you're giving the feedback to.
And thanks again, I'm very happy to discuss this study, my contact information is here.
Thanks to all of my co-authors on this paper - Sanuri, Peter, Isabelle, Lola, and Emerson - and thanks to Google for funding this work.