Ultimately, the job of engineering leaders is not to code—it is, instead, to remove obstacles so their teams are able to spend more time working on valuable solutions and so their work output has the reach, impact, and visibility it deserves. So it would be easy enough to designate code review as the engineers’ domain, where managers need not tread.
But that makes for a massive missed opportunity.
Without guidance and a healthy review culture, the PR process can disintegrate into unproductive, though understandable, behaviors. Some developers see code review as pulling them away from their true work, and it’s impossible to deny that review is a somewhat subjective process that, unshepherded, can lead to disagreements, stalled commits, and even outright hostility.
Many individuals also have not experienced the art of accepting and giving criticism, and therefore haven’t learned it. Unintentional communication breakdowns can lead to both social and technical frustration, which of course gums up the works too.
These sorts of PR environments are not sustainable or healthy. That’s why managerial support is critical, if reviews are to become opportunities for teams to learn from each other and work toward more effective, more creative solutions.
This holds true with engineers of all levels. Engineers new to the organization (or new to the industry) glean the team’s culture, pace of work, style, and implicit coding standards through involvement in the PR process. Senior developers are able to coach more junior ones in their domain expertise, and for engineers of all levels, code review is a chance to identify strengths and weaknesses (both individually and organizationally). And for co-located and distributed teams alike, code review is perhaps the richest opportunity for work-centric socialization and team-building.
So where do managers take part in this process?
Where training was once at the heart of management, code review is now the prime way of improving an engineering team’s output. By participating in and observing code review, managers are able to track the health and productivity of the team, which provides insight into where to intervene and where to encourage progress.
In other words—the team is responsible for creating code and for peer reviewing that code. Managers are responsible for the behavioral trends exhibited in their teams’ code reviews.
In our work, we’ve learned to recognize common patterns exhibited by software engineering teams—both successful patterns that can be nourished, and problematic ones that an aware manager can remedy. Here, we’ve assembled eight of those dynamics that demonstrate the behaviors common to developers and to engineering teams, how to recognize them using GitPrime metrics, and what managers can do to bolster their teams’ health and productivity.