Peek into the brain of a code reviewer in Betsson Group

The motivation behind conducting this survey came from my own small and straight-forward pull request(PR). I sent it to one of our gatekeepers(GK) and I was standing behind him while he was reviewing it.
(GK is a role within one of our front end departments(OBG), who has the final say within a PR whether it can be merged or not).

I was confident that my logic was on-point and no comments will follow. The mysterious GK had been staring at my changes(few lines) for more than a few minutes already. In the back of my head I was thinking:

“Come on… lets go, it’s perfect!”

But then, he opened his mouth and shattered my world. My logic wasn’t invalid, but even further optimizations could be done and I was totally amazed. That made me curious about what was going on in the reviewers' heads. How do others think, what questions do they ask, etc.

This survey is a light reflection of what is going on in the heads of the reviewers in Betsson Group.

Image by jambulboy

Survey description

The survey consisted of 10 questions: first 5 were mandatory, rest optional.
It received 31 answers, 12 of which were from GKs and 19 from other developers. In the survey, I purposely made a distinction between GKs and developers in order to find out whether there are certain secrets within the groups.

Do you enjoy doing code reviews?

91% of GKs like doing code reviews and enjoy the added burden of their role.
84% of developers enjoy doing code reviews.

Are you responsive on Slack/Outlook/etc after you started doing a code review?

75% of GKs are responsive while doing a code review. For the rest, it depends on different circumstances.
84% of developers are responsive while doing a review.

Based on these numbers one could come to the conclusion that GKs are a bit more focused and don’t let themselves be distracted that easily.

What is the first thing you do when you start doing a code review?

For this question, there was no clear distinction between GKs and developers. For both groups it was basically 50/50 — one half starts by opening the JIRA task and the other starts by checking the code.

Even though the question was about the first thing you do when starting the review, I mostly received flows on how code reviews are approached. Almost all of them include checking JIRA at some point during the review.
Exceptions are made when the PRs are really small and straight-forward.

What questions do you ask yourself during the process?

Once again no clear distinction could be drawn between the groups, but here are the most recurring questions/thoughts/ideas from the answers starting with the most featured ones.
The number behind the question means, how many times it was mentioned.

• Could this be improved, made simpler & shorter? (20)
• Does this fit into our application structure & coding standards? (10)
• Could there be any edge cases that are currently not handled? (7)
• What is the purpose of this code? (7)
• What would I have done differently? (5)
• Could existing code be reused? (3)
• Performance-related questions(speed & complexity) (3)
• Could this cause bugs within the feature/application itself? (2)
• Is this really needed? (2)
• Are there breaking changes? (2)

Imagine someone submits a really sloppy PR. Would it affect your reviews on that person in the future? How?

This was a mix of yeses and noes. No clear distinction between the groups could be made.

Based on the replies I can safely state that if you accidentally submit a sloppy PR/are fairly new to the project — it’s fine. Reviewers will do their best to write constructive feedback, share links to documentation, etc.

I can also claim that most of us are rather patient, but if sloppy PRs become a repetitive pattern and one fails to learn from the feedback, then everyone has their limit. You might end up losing your credit, reviewers will become pickier and trust the quality of your changes less.

What makes you quit & close the code review?

Within this question, one clear distinction could be made. Not a single GK quits a code review because of its size, but half of the developers quit or don’t even start one when it’s too big.
This might be caused by the fact that PRs can’t be merged without approvals from GKs and therefore they are obligated to check them.

Here are some of the other reasons why people quit.

• Not enough time (7)
• Not familiar/lack of understanding within the particular area (4)
• Comments are left unanswered (3)
• Many reviewers and big discussions already present (2)
• Failed builds, hardly understandable code, confusing JIRA tasks (1)

Any suggestions for your friends & co-workers on how to get better at doing code reviews?

• Take time & do more code reviews (9)
• Keep the comments constructive and friendly (4)
• Understand what the product & code should do (3)
• Read comments & other reviews (2)
• Plan ahead, make the PRs small (2)
• Be responsive to comments and let reviewers know when changes are applied (2)

What was the single most important thing for you personally that made you better at code reviews

• Dedicate time & do more (12)
• Read other reviews & comments (4)
• Experience (2)
• Side by side diff > unified diff (1)
• Take responsibility for the ticket & code you’re reviewing (1)
• Do not take comments personally (1)

Conclusion

Based on this survey no factual conclusions could be made.

One could assume that GKs are a bit more strict when it comes to letting themselves be distracted while doing code reviews, but the difference is rather minor.

GKs also don’t shy away from big PRs, but that might be caused by the fact that none of them can be merged until there are approvals from GKs. Tackling these bigger reviews could be very challenging, but they’re probably very rewarding and educational as well.

I sincerely hope that there was at least something that you were able to take away from this article and add into your own toolbox when it comes to doing code reviews.

Live and breathe tech? Then Betsson is the place for you. Join the team! betssongroup.com/career