Developing a Culture of Mentorship with Code Review


Donald Trump does it on “The Apprentice.” Senior citizens do it when they volunteer to teach young children to read. University alumni guiding recent graduates do it. Mentorship relationships are all around us. And for good reason.

According to this article in Forbes, Sun Microsystems compared the career progress of 1,000 employees over a five-year period. And what did their findings tell them? “Both mentors and mentees were approximately 20% more likely to get a raise than people who did not participate in the mentoring program.” They also found that employees who were mentored were promoted five times more often than those that were not.

While mentors in all professions are important, I’d like to focus on mentor relationships for developers. Business mentors typically meet to get general advice about career advancement, to discuss new ideas for a business venture or for help navigating office politics. Mentoring in software development is inherently different. It’s about sharing your expertise, knowledge, and experience with younger developers so they can become better programmers.

There are two basic flavors of mentoring for software developers: formal and natural.

Formal mentoring happens when either a company requires senior developers to meet with junior developers for coaching on a regular basis, or when two people sit down and agree to create a mentoring relationship for a set period of time.

Natural mentoring happens as part of your daily workflow. For example, a senior developer could decide to look out for a younger developer on the team by teaching them as part of their regular interactions. Or, what happens more frequently, is that mentoring naturally develops along with every developer’s workflow in the code review process.

Natural mentoring during the code review process has a lot of benefits, including:

Frequency & Consistency:

People adopt lessons faster when they are applied every day. Because code reviews are done on a regular and ongoing basis, as part of your job, you don’t need to worry about setting aside special times for mentoring and skill development.

Everyone Benefits:

Junior developers have a fresh perspective. Sometimes they can point out an obvious answer that more senior developers might have overlooked. By using code review as part of your mentorship culture, everyone gets to learn, not just the junior developers.

Tracking Built In:

Since the best code review systems allow tracking of changes and comments, junior developers can refer back to previous mistakes or pull up a reviewer’s comment for further research or discussion.

Sets the Priority:

If you don’t make the mentorship a priority, a junior developer will sense that it’s not important. By baking it into the code review there can be no doubt in anyone’s mind that it is an essential part of the team’s culture.

Knowledge Transfer:

Code reviews create a way for senior developers to exchange information and transfer knowledge easily, and without interrupting their regular work processes.

Ready to get started? Here are some tips and best practices for conducting code reviews for mentoring:

  1. Review often. If you have a host of changes to do, it’s better to break it up into a series of small reviews, rather than cramming everything into one giant review. This helps people stay focused and interested. It’s also easier for authors to learn from smaller reviews rather than be overwhelmed with all of the bugs found in a larger review.
  2. Be Constructive. Make sure that you are making comments about the code and not the author of the code. You want to create a culture where people want to work together and are comfortable making comments. Few of us take feedback well, so be nice about it and give accolades when corrections are made.
  3. Write “correct” code examples. If you end up writing some code as a teaching example, be sure to write clear, well-constructed, high-quality code. There are a ton of ways to learn code writing circulating around the web, and you may run into some bad habits picked up by junior developers. Help them understand the best practices by writing clear examples.
  4. Be accessible. If possible, make yourself available in person or over the phone. Using a code review tool greatly helps with mentoring junior developers by tracking and saving comments and bugs. It also allows any in-person time you might find to be more than just your typical ballgame talk. If you are developing mentoring relationships by doing code review, it will naturally extend into other conversations around the office.

If you already do code review with senior or junior developers, we’d love to hear your mentoring stories and tips. Feel free to share them in the comments below!

The Complete Guide To Approaching Your Development Team When They Write Bad Code

In our newest eBook, The Complete Guide to Approaching Your Development Team When They Write Bad Codeyou will learn:

  • How to approach your developer’s bad code
  • How to build the appropriate strategy before having the conversation
  • How to collectively take responsibility for bad code
  • How to set a coding standard within your team

Get your copy!




  1. Igor Popov says:

    Wow, this is a really nice post… and not only this one, there’s tons of quality posts here! thanks for sharing 🙂 and please write more.

  2. Caio Cézar Lopes says:

    That is a very interesting and useful post. We started to implement Code Review recently in our company and good results were achieved. I think this is one of the best forms to coach Junior Developers.

  3. Mentoring for quality assurance executives is a must have thing which will surely help them to generate some great ideas and tricks while coding for a specific software. Upper management has to think about and must endure a strategy about implementation of new training’s and exhibitions so as to have a culture of mentor ship. As motivating and coaching are the two basis aspects of mentor-ship in an organization so it will eventually leads to increase the motivational skills of employees. it will eventually improve overall proficiency level of employees as the time passes.

  4. Code reviews can be useful. But before reviewing the code, I always rather would review the design first. If we review the design, so much will usually change, that first reviewing the code is a waste of time. Even if not much will change, having the design will help in understanding what the code does.
    Often there is no design. Then we ‘reconstruct’ the design, which usually exposes issues quickly.
    So my preferred process is: review the requirements until happy – review the design until happy – then review the code until happy. Result: no defects found in test and use.
    Until the user says: “Exactly what I asked for, but not what I need.”

Speak Your Mind