Dealing With Code Reviews
A series of short tips / advices for Software Engineers
A recent study I conducted found that 14.89% of Developers were recently offended by comments in a code review whilst 36.17% were “Kind of Offended”
“Roughly 50% of Developers sampled were “offended” by comments in a recent code review”
The Scenario
Sibo has just finished his task that involved importing a daily dump of data, computing and adding to the existing database. On his machine, it works great. Sibo commits his code and submits a pull-request and asks his colleagues to review the code.
Gill has resolved a major production issue and then decides to pick up Sibo’s review and starts noticing a few issues around the order of complexity of his code. She adds the following comment and requests changes:
“This is wrong, it will kill the server”
The Impact
This code could potentially “kill” the server and cause major issues if it were to be deployed. This comment would more likely negatively affect the spirit of Sibo if the correct team structures are not in place.
I don’t think we want to hear the words “show empathy” or “be more sensitive” anymore. We may have become desensitised to the numerous articles on showing empathy within teams. Should we perhaps re-think about it?
“Are we desensitised to the words empathy and patience?”
This could affect Sibo in a few ways (as Developers I am sure we are able to relate — particularly the 50% that recently felt offended)
- Feels like his code was not good enough
- Feels like he wasted his time
- Feels like next time he should just follow the others thought process
When asked would you potentially leave your team based on a bad code review process, 6.38% said yes and 25.53% said maybe. That is quite staggering.
A quarter of your team would consider leaving due to a bad code review process
An Alternative
It is difficult to rationalise/deny feelings so I suggest a change on both sides of the review process.
Reviewer:
Based on my study 23.40% felt that they offended someone and 31.91% felt they kind of offended someone in a code review.
More than 50% of reviewers are aware that they may have offended someone
Some suggestions we could use to improve this:
- Consider the words used in your review, use words such as “perhaps we could”, “maybe we could try”
- Be open and accept alternate ways of doing things that may not be your norm.
- Understand when we need to put in that extra effort to make things “perfect”. If it is something of very low importance it does not make sense spending an extra 10 hours to make it a bit better.
- Understand it is easy to say don’t take it personally, but as human beings, it is in our nature to take things we value personally.
Reviewee:
- Be open to feedback, it is the first step to growth.
- Understand feedback is for your own growth and the success of the project. Do not put your self-worth into a code review.
- Teammates usually have a strong attachment to the code (and it is a good thing) so understand that is why they sometimes react the way they do.
- Try to take it less personally, yes it is normal to take feedback personally but in most cases, the feedback is never directed at the Engineer.
Team:
- Create safe places for team members to voice their opinions about “unfair” review processes.
- Understand when to let things go.
- Identify team members under strain (that 25% that could leave and others who would end up being unhappy and unproductive).
Final Comments
Based on my study of Software Engineers in South Africa they gave code reviews an average importance rating of 9/10, however, 38.30% mentioned they could maybe use their time more productively.
Importance of code reviews: 9 /10, yet 38.30% could spend their time better
This makes one think is the process perhaps flawed? Is it missing something? Do we need to perhaps be a bit more conscious in our reviews and understand we need to consider the people, technical and business when conducting a code review?
Consider People, Technical and Business in Code Reviews
