Devs Are Quitting Because of Poor Code Review Practices
Code Review
The code review should be an opportunity to learn from others in your team. In fact, it is a good opportunity for colleagues to act as the first line of defence for both code quality and the end customer (so internal and external customers).
Yet in many companies, the code review has become something different. A tool for the worst aspects of software developers to come to the fore.
The Power-Play
Perhaps the most visible sign of a broken code review culture.
Photo by GR Stocks on Unsplash
When new developers start in an organization there is usually a process where they are hazed by the existing developers. That is, code reviews are rigorous to the point of being blocked over the naming of variables (which brings to mind discussions at my place. An object holding an array of countries took several hours of back-and-forth for instance, almost missing an important deadline set by the business).
Other techniques include enforcing an unwritten style guide or one that changes depending on who is writing the code (in a performance review I once was sent a Google style guide. Why was that only given after issues had been found with the code? Because the senior developer made up the rules on the fly).
A Nitpicking style
Photo by Kevin Wenning on Unsplash
Always a favorite when you are working to get code out on a really tight deadline. A line break there? Let’s get rid of that. Can we space out these variables from these other variables using line breaks? What about getting these imports in alphabetical order?
The list can never end. One of my previous colleagues would demand that list be in alphabetical order, too.
Unevenly Applied Conventions
Some style is purely subjective and unevenly applied even within the same team. This is often due to a rank order of seniority or reputation (as opposed to an order of competence).
Photo by Marvin Meyer on Unsplash
This is a sign of a toxic team that, as a seasoned developer I would advise any developer to leave at the first available opportunity.
Any developer will be measured by their fit for the team (often at the expense of diversity, this doesn’t work if you look or sound different from your colleagues in any significant dimension) and whether you have got on the wrong side of any powerful members of staff in your organization.
The concern, and something I’ve experienced, is that no matter how good your code is compared to your peers, is that you are actually compared to an idealized version of your colleagues. You’ll have little chance of changing this opinion until you leave, and I think this would be better for you if it were sooner rather than later.
Speeding up Code review
A longer code review process can mean that developers can miss deadlines. Waiting for colleagues to look at code is never pleasurable. So what might the solution be?
In my experience, the wrong one.
Imagine the meeting. The number of developers within a squad is too small to perform code reviews within a decent amount of time. It is noticed that only one approval is required for the code. The suggested solution?
Let’s get two developers to approve the code before merging into develop
That’s right. To speed up the code review process insist that two developers approve the code rather than one. This is meant to solve the problem of developers being unavailable for code review. Seriously?
On the other hand, there are plenty of examples of merge conflicts as developers try to work on their next ticket before the previous one has been approved.
How about we work on the root cause of the problem with Code review? A real lack of teamwork within tech companies means that people are not being truly collaborative.
I think perhaps the real question to ask is why we don’t perform Code reviews face-to-face (and I don’t mean on Zoom).
Conclusion
Most of the issues with Code Review are solved problems. A linter (in whichever language you might use) should automatically solve many style issues, in much the same way that FE functionality can be tested through UI tests. Manually looking at code to enforce consistency? More experienced software developers thought that these practices would have been automated at the start of this century. I guess not….