You Want to Be Liked? Review Your Colleagues’ Code!
Photo by Vincent Battault on Unsplash
The Secret Developer recently wrote an article about one of their ‘Senior’ developers' code reviews. However, this isn’t their only recent thoughts about Code Review. Here is what is happening, and crucially why The Secret Developer thinks this is when the code review got personal. Here’s the situation, why that’s damaging to the whole team, and what needs to happen to fix this situation.
Reciprocity in Review
“Code Reviews are an important part of software development. I’m the sort of software dev who tries to hit the quality bar in whatever I do. That means the quality of code, my candace, and the reviews I give others.
So, I generally raise between 0.5 and 3 pull requests a day, and review ~5 pull requests a day. I usually review code within an hour or so of it being posted) sometimes much faster.
I expect that for each review I do for you you’ll give me a review back all being equal. That’s why I’m disappointed I can wait up to 2 days for a code review.”
Damaging The Entire Team
“There is a large degree of variability here. Perhaps my pull requests are somewhat larger than my colleagues. Perhaps my work is somewhat more complex than the rest of the team’s pull requests.
I would say that I’m creating small pull requests. I’m the only one in the team who gives a context for my PR. Sometimes I’m waiting for a review so, I review someone else’s work, approve it and it goes through onto the CI. I’m still waiting for another 4 hours for my review and I guess my colleague is off working on something else (sure I’m working on something else at the expense of conflicts and difficulties across branches, a cost I bear).
This is damaging because, at this point, I hate the entire team. I waited a whole day for a review which was then blocked because my colleague didn’t read the context and had a ‘quick question’, or worse didn’t understand the basic features of our language and was confused. It’s a mess and I don’t think this is mine to clean up.”
Fixing the situation
“To fix this we need to document the process. I tried to look at the team documentation for this and drew a blank (no surprise).
I’ve tried stopping reviewing my colleagues’ work, but I’m so deeply isolated in a silo that superfriends just review each other’s work and ignore mine. I also like reviewing others’ work as it works like free training, and I can see what is happening across the codebase.
I think the way to stop this happening to me is to leave.”
The root cause
The Secret Developer has been known to write nit-picky and annoying code reviews. It is perhaps not surprising that their colleagues have not taken well to them and in the team, they are not popular.
In software development it should be recognized that working in a team is important and working well with colleagues is important when producing quality software rather than just the quality of any individual team member.
I think the team at work hopes that The Secret Developer gets the memo someday.
Conclusion
Although code reviews are an important element of software development there is something more important than the process. The people.
As we move into an AI future, we should be looking to do one thing that AI cannot (yet) effectively do. Work well with people.
” In all fairness, we all know it cannot yet write good code. Also, I don’t need to work with other people as I work in a silo on my own.
Read the article before criticizing me, thanks. “