Mentoring is the practice of assisting people with their learning and career growth over a long period of time.
Although it’s a well-established practice, it’s not so common in the tech industry. In the majority of places that I’ve worked, mentoring was either underused or non-existent. That’s a shame because mentoring can be crucial to levelling-up as a software developer.
Why is mentoring important?
The prevailing attitude for professional software developers seems to be that you go to college and study for three years, and come out the other side knowing everything there is to know about building software. Many people effectively stop learning once they land their first job.
I say ‘stop learning’ but of course most developers are learning each day, perhaps via StackOverflow or blog posts like this one. Unfortunately this is not deliberate learning. Deliberate learning means working towards a specific goal, and that goal is generally much larger in scope than the scattergun approach that you adopt when working through your daily tasks.
While incidental learning is still learning, you’ll ‘level up’ at a very slow pace compared to deliberate learning. That’s why we have the old adage, “they might have 10 years’ experience, but it’s just 1 year repeated 10 times.”
Mentoring is so important because it enables deliberate learning: it stops people falling into the ‘repeated year’ trap.
What makes a good mentor?
All you need to be a mentor is a skillset that someone else wants to learn. Most mentors are not mentoring full-time: they have their own jobs and mentoring is something they do in their spare hours, because they want to help others, and they almost always do it for free. It shouldn’t take up much of your time–no more than a couple of hours each week.
It’s not the job of a mentor to teach, although you might end up doing a little bit of that. Your role is to guide.
So while there’s an element of teaching to mentorship, the skills a mentor needs are different to those of a teacher. You need to be an attentive listener, and you need to have enough practical experience to be able to give your mentee the right advice at the right time.
Guided learning
Unlike other professions, mentoring software developers requires more than just giving advice. You’ll need to assign practice coding projects from which the mentee can learn. It might also mean asking your mentee to read books, write blog posts or learn how to use new tools.
At the beginning of the process, both mentor and mentee work out what the long-term goals are, and map out steps to get there.
For example, let’s say the goal is to become proficient in object-oriented design. In order to achieve that goal, you could do the following:
- ask your mentee to build a variety of programs in Java,
- help them learn Smalltalk to understand a historical perspective,
- suggest a reading list of books to work through,
- ask them to write a series of blog posts demonstrating their newfound knowledge.
That being said, not all mentees will have the luxury of having spare time to work on side projects. For these developers, another option is to help guide the work they do for their employer, by reviewing their code on a regular basis and being ready to provide advice or suggestions if they ask for it. You could also try building up a relationship with their manager or team lead so that you have an opportunity to influence what your mentee might be working on next.
Reviewing work
A regular planning meeting is essential to make sure the mentee is on track: perhaps once or twice a month, or once a week if you can manage it. It could be as simple as a 30 minute phone call.
A mentor should review work and give feedback. You want to check that each piece of work demonstrates that something has been learnt, and that their skills are improving. I’m not saying that their work needs to be perfect: particularly when reviewing code, it’s not the mentors job to insist on any level of quality.
A team lead or manager should be reviewing code to ensure it meets the right standard. But the mentor’s role is different. You’re looking to see what progress the mentee is making towards their goal, and to figure out what the next assignment should be.
You should also be happy to leave assignments unfinished or of substandard quality if you think the mentee will learn more by switching to a new assignment.
Enable your mentee
A mentor should be an advocate for their mentees. This is a very important duty. Over time you will form a close bond with your mentee: you’ll have a very keen awareness of their abilities, their strengths and their weaknesses. You will be the first one to know when they are levelling up with their technical skills. This makes you perfectly placed to suggest them for job openings and new opportunities.
You should use your personal network and your own social standing to help your mentee step up in their career. This is sometimes called sponsorship. Take every opportunity to speak up for them. This can require very little effort on your part, but can have a powerful positive impact on your mentee.
Build an ecosystem of skill
Rock-solid development teams are rarely made up entirely of senior developers. Instead there’s a gradation of skill levels between individuals, and this gradation helps with the social dynamic of the team. An ecosystem forms that makes it simple and almost natural to find mentor-mentee pairings.
Anyone who has ever had a great mentor knows the value in having one. Mentors are not just for junior programmers, they are for everyone. So why not encourage everyone on your team to find a mentor? Even mentors need mentors!
This is one of the core ideas from within the software craft community, which talks about the notion of ‘life-long learning’. They rely on each other to teach and to help individuals level up.
Implicit mentoring
You don’t need to have a badge saying ‘mentor’ in order to be one. You can make a conscious choice to be someone’s mentor without having to give it an explicit name. This is a useful trick if your company has no history of formal mentorship and you’d like to start doing it.
You could start with a new hire who’s fresh out of college. Ask politely if you can help review some of their work, and enquire what technical designs they’ve come up with recently. You could try lending them a book that has helped you in the past. This is enough to get the ball rolling. With any luck, they’ll be receptive and appreciate your guidance.
The best teacher is practice
Hopefully I’ve given you the confidence to get started. There’s so much to learn about mentoring that you really just need to dive in and make course corrections as you go along. It should be an enjoyable and rewarding experience.
Latest comments (5)
Looks like there is some sort of collation issue or text formatting issue on your ‘. Not sure if you upload the text or if it’s with dev.to. But definitely an issue with wrong collation or character formatting.
Thanks Daniel! I definitely like the part on doing code reviews in order to see whether or not your mentee is making progress regarding their goals as opposed to whether or not they are writing good vs. bad code. Sometimes you're in a position though where you're both, a mentor as well as working together on the same project with your mentee, then you're acting in both roles. Then to me at least in the beginning the "focus on your mentee's goals" was the bigger motivation when doing code reviews.
Also one question. What's your experience with people joining your company that are already very experienced but you'd still want to give them the chance to learn. Do you then try to forward those people to other even more experienced co-workers in your company or something like that?
Hi Benjamin, thanks for commenting! I agree that roles get muddy when teams are involved. For example, mentoring tends to be the first thing that's lost when there's time pressure.
I have some experience of bringing in very experienced people. If I think back to those occasions, I think there needs to be a large degree of self-awareness on their part so they can clearly articulate what they want to learn and what their growth areas are. If that can be done, then it's entirely possible for them to learn from less experience co-workers.
For example, teaching is a great way to learn. So an experienced developer can find opportunities to teach a topic to one or more entry-level developers, as a way to learn themselves.
What are your thoughts on that?
Haha you‘re right, Daniel!
I like how writing blog posts is an advise I am hearing from so many different places lately. Must be something about it ;-)
When I was just trying to think of one particular situation, I am not sure if the topic my college worked on is interesting for people outside of our team but it’s definitely worth having a look.
Thank you!
Good introduction, thanks Daniel