I would like to thank Baptiste Barbieri, Antoine Guy, Maxence Zajdlic and Rafael S. Ward for their time <3.
Code review is one of the most used...
For further actions, you may consider blocking this person and/or reporting abuse
Nice title, just clickbait-y enough to bring someone in but then holds to it argument. I think you basic thesis is more or less correct. Sadly pairing/mobbing can be quite difficult in many circumstances. Another thing to note is code review, or at least PR approvals are sometimes needed for regulatory purposes.
I wrote a bunch of words addressing a lot of the individual types of failure and where the break down comes from. But as you say the common patterns applies to most issues; Most of which can be solved with early feedback.
First type of issue: Failure of specification.
The task specification failed to properly explain what was needed. This manifests as the ping-pong, redesign, not working, and after merge types of failures. The implementer did not fully understand what they were supposed to do, the 'wrong' people were assigned and/or the 'right' people were not consulted.
The solution here is for the implementer to ask questions early in order to understand the work and for others who are 'area experts' to review the spec and approach. Having clear and documented implementation patterns also helps here.
Second type of issue: Failure of process.
The team's development process and tooling failed. There are two flavors of this the hard and soft. The soft failures are team process failures. These often manifest as the elderly, keep rebasing, TL;DR, waiting for and sometimes too small failures. In these types of failure the team's process does not allow for or emphasize the importance of code reviews. And more importantly team likely does not divide things up appropriately to avoid conflicts in the code and overly large amount of work.
Third type of issue: Failure of responsibility.
This really catches everything and is the most human and difficult part. A lot of the issues that manifest during issues with code review can be boiled down to the fact that most software developers think of themselves too much as coders. It's an easy trap to fall into to think that writing code is your job and everything else that you do is distracting and taking time away from that. There is so much more to being a developer/engineers than that.
Implementers must: talk to the PM and/or designer to make sure they understand the specs of a request. Additionally they should communicate back to the requester if there are any major technical issues that exist that could cause an issue with an implementation as specified. Implementers should also often communicate with other engineers to vet their intended implementation. Finally after implementation, usually in something like a PR, they must communicate to those reviewing the code if there are any ambiguities or particularly complex pieces.
Reviewers must: realize that reviewing code, vetting implementation ideas, and otherwise assisting their fellow engineers is part of their job too and not just a distraction from it.
Managers/Leads must: ensure that they create a team environment were the two above points are emphasized and respected. People should never be afraid to ask questions and feedback channels must be open and amicable at all levels.