It’s not easy to find and retain skilled senior engineers, and research suggests that direct replacement can cost as much as 50 percent of their annual salary. But with the right amount of support and training, organizations can get junior developers to contribute higher quality code.
Many companies use mentors as part of their onboarding process for all new hires. At my previous job, we assigned a “buddy” to each new employee. The “buddy” was usually a senior developer who could provide technical mentorship, help the new team member get up to speed with the codebase and answer their process-related questions.
A 2006 Sun Microsystems study reveals that mentorship can be beneficial for both parties. Out of the 1,000 employees who participated, researchers found that mentors were promoted six times more often than those not in the program, and mentees were promoted five times more often than those not in the program. They also found that retention rates were much higher for mentees (72 percent) and mentors (69 percent) than for employees who did not participate in the mentoring program.
In one chapter of her book, The Manager’s Path, Camille Fournier describes her first mentorship experience as an intern at Sun Microsystems. She emphasizes that the onboarding mentorship role was used as an opportunity for both parties:
The mentor gets the chance to see what it is like to have responsibility for another person, and the mentee gets an overseer focused on them alone, without other reports clamoring for the mentor’s attention.
I’ve had varying levels of support in my career. At my first internship, a senior colleague showed me to my desk and explained the project that I would be working on; then he left me alone for the entire stint. I was not given any guidance or support. When I summoned the courage to ask for help, I was met with my colleague’s impatience and irritation. I felt lost and was quickly discouraged.
My first job at a small startup was the exact opposite. Instead of being shown a desk and abandoned, I was set up with a mentor: Julian. During the first weeks, we had many pair programming and code walkthrough sessions. It was very beneficial to me. Thanks to Julian’s support, I was able to get up to speed quickly and start contributing. However, in the following months, this mentorship started turning into micromanagement. We had daily stand-ups on the team, but in addition to that, I had to make daily reports to him. This was in addition to an unnecessary weekly 1-on-1 meeting.
The thing is, that was his first mentoring experience. Now that I’m a senior engineer, I can sympathize with him. It’s not easy to gauge how much help a junior engineer needs.
Having been both a mentor and a mentee, I’ve found that good and useful mentoring experiences share the following core points:
Prepare a non-critical task that they can get started with
If you are assigned a new mentee, they are most likely a new hire or an existing employee joining your project. Either way, the first thing you can do is have them download the source code and successfully run it on their local machine. Onboarding documentation and project ReadMe files can quickly go out of date. When a new team member joins, I ask them to update any dead links or add any issues they have found to the troubleshooting section in the project’s ReadMe. That way, the mentee gets to make their first contribution to the project and familiarize themselves with our git-flow. The next hire will have a much easier time setting up the development environment.
Before the mentee gets started on the assignment, give them a high-level architecture overview, and walk them through the code. The main challenge here is not to overwhelm them with information. Give them the time to discover the code base and try things out on their own.
Prepare a straightforward task that they can start working on to introduce them to the codebase; the assignment should not be critical and should not block anyone else. This way, they don’t feel any added stress. A front-end developer might start working on fixing a UI bug; a typical task for a backend developer could be making some change to a RESTful endpoint.
Before diving into the code, start with a planning session. Depending on the mentee’s technical level, you might need to break down the project into smaller chunks.
Listen carefully and communicate better
According to Camille Fournier, one of the early lessons in leadership — whether it is via direct management or indirect influence — is that people are not good at saying precisely what they mean in a way that others can precisely understand.
We often fall into the curse of knowledge and assume that our interlocutor knows the context as much as we do. In talking with your mentee, try to be as clear as possible. That means that you need to be prepared to explain something in a few different ways.
Earlier this week, during a code review, I was explaining to my junior colleague why two tests he wrote were testing the same use-case. I struggled to get my point across, and I had to formulate my explanation differently a few times.
Your mentee might not be at ease in asking questions or asking for help, for fear of looking stupid. I encourage them to ask questions, and I even ask the “obvious” questions myself to make sure that we are on the same page.
Having suffered from imposter syndrome, I always try to lower the barrier by admitting when I don’t know something. During a recent problem-solving session, I forgot the name of an array function in javascript. It gave my junior colleague a chance to step in and explain something to me. If they hadn’t, I wouldn’t hesitate to look it up in front of them.
Teach them where to look for answers
Having a mentee can take a lot of time. During the first weeks, you should be available to answer their questions and have frequent check-ins. But after a while, they should know where to look for answers.
If I find that my junior colleague interrupts me to ask questions that they could have looked up themselves, I try to communicate that they need to do some research on their own before coming to me.
If they want to discuss a possible implementation with me, I first ask them what they have already tried. I ask them to either write a request for comments or push a work-in-progress pull request. That way, we have a clear basis for discussion, and other colleagues can jump in and provide feedback as well.
Instead of readily giving them the solution, it’s important to show them how to work out solutions on their own. In problem-solving sessions, teach them how to debug code. Point them to the documentation of the libraries or the language you are using for your project.
What to keep in mind during code reviews
I’m always surprised to hear that some companies don’t do code reviews. This 1988 study found that every hour spent on code inspection saved 33 hours in maintenance.
Code reviews can be an excellent opportunity for knowledge sharing. They are a great way to teach best practices and good programming patterns.
During a code review, ask questions and suggest alternatives. It’s essential to be mindful of the way you express your feedback. Things like “WTF,” “This is bad,” etc. are not helpful to your colleagues and are only going to frustrate them.
Instead, if you think something is not correctly implemented, explain why you think your way is better. Learn to understand the difference between personal preference and essential changes.
Assign code reviewing tasks to the mentee as well; this teaches them what to look for during a code review, such as code clarity, variable naming, etc.
How often do you need to check in on them?
During the first weeks of the mentoring relationship, you are learning the frequency that you need to check in with your mentee. Because I’m not too fond of meetings, I ask mentees to reach out to me when they need support with something. I let them drive the schedule and the topics they want me to cover.
However, in my experience, when you give a mentee too much space, they might not come to you if they need help, for fear of disturbing your schedule. So you still need to check in every once in a while. I try to ask them every week how they are doing. If I notice during stand up that they are struggling with a task, I reach out and offer to help.
The most effective mentoring relationships develop naturally. When a senior engineer mentors a junior engineer on the team, they can work on problems that are relevant to both of them. It’s essential to include the junior engineers in any planning or problem-solving session. These turn out to be great opportunities for knowledge sharing. Senior engineers benefit when the mentee can produce higher-quality code and require fewer reviews. And junior engineers grow when they have access to someone with a deep understanding of the codebase.
References
Research on the cost of direct replacement: https://www.shrm.org/hr-today/trends-and-forecasting/special-reports-and-expert-views/documents/retaining-talent.pdf
The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier.
Curse of Knowledge: https://en.wikipedia.org/wiki/Curse_of_knowledge
Research on code inspection: https://www.ifsq.org/finding-ia-2.html
