Programming is not a zero-sum game. Teaching something to a fellow programmer doesn’t take it away from you. I’m happy to share what I can, because I’m in it for the love of programming.

– John Carmack

Devs, the temptation is often to keep the head down and keep churning out code. This is sometimes seen as the most effective use of your time. You are paid to be a software developer after all so the act of writing software should be what you are doing, right? Well, not exactly!

If you are a software developer, particularly if you are a senior software developer, it may be more helpful to view yourself not only as a person who writes code but as someone who provides input to other stakeholders and removes barriers to the successful delivery of software. Often times, this can mean unblocking and being a force multiplier to the junior developers on your team. Often, this is the most important thing you can be doing with your time.

Consider this. Think you’re being a rockstar and saving the team by pulling an all-nighter or coming into the office at the weekend for a solo session? Think again! If all you do is write code, you might actively be making things worse. Code only lives if it is understood. If the codebase is materially changing without periodic check-ins with the other collaborators of the codebase and if you are the only one that understands that part of the codebase then you are doing negative work. If you’re crushing code, while members of your team are stuck, you’re actively hurting the team. Worse yet, if you’re causing your team members to get stuck by confusing them with material changes brought about by out-of-office-hours coding sessions then you may need to reflect on whether you are actually making negative contributions to the team.

To ensure all developers on the team are on the same page, it is worth periodically reviewing and refining the agreed coding standards for the team, together as a team. This can have a number of benefits including collective learning, reflection on whether current approaches are fit for purpose and for determining if any members of the team are struggling. Senior developers and managers should make a safe environment for everyone to ask for help when they’re stuck. This could be through requesting a more thorough code review or through some 1-on-1 mentoring, for example. We can model this behaviour by asking for help ourselves!

Having agreed standards allow the team to conduct code reviews more effectively because code standards can remove any subjectivity and bias in the process, i.e., the discussion on the code diff is around whether the code meets the agreed standards and not what the standards should be. It can also help in producing documentation that junior developers can be referred to (especially useful during new employee on-boarding!).

Peer review can put a strain on interpersonal team relationships. It’s difficult to have every piece of work critiqued by peers and to have management evaluating and measuring defect density in your code. Therefore, in order for peer code review to be successful, it’s extremely important that managers create a culture of collaboration and learning in peer review.

While it’s easy to see defects as purely negative, each bug is actually an opportunity for the team to improve code quality. Peer review also allows junior team members to learn from senior leaders and for even the most experienced programmers to break bad habits.

For a code review process to be effective and for all team members to derive the full benefit from it then it is important that managers, particularly managers of senior developers, do not penalise people in their reviews for taking the time to help other developers, particularly junior developers. Even if the senior spends a large portion of his/her time helping juniors, it’s a good use of his/her time.

“This code is our code” should be the mantra of all high-performance software teams. It is important to try and cultivate collective code ownership all the way through the process. All pull requests should be respected as an intellectual extension of the code base. Mostly there are no right or wrong approaches, but just different personal tastes. For often discussed problems (indentation, naming, etc.), these should be incorporated into coding guidelines that are collectively agreed upon at periodic reviews. Apart from that, the standards should be relatively flexible as slight deviances in style are a natural reflection of the fact that coding is in itself a logic-based creative process and every coder will have his or her own style. Allowing affordances to these deviances and only supplying guidance, not criticism, where appropriate can ensure a happy and productive software development team.

Happy coding.