A significant part of my job is mentoring junior developers. Being a mentor is like being a tour guide. You’ve got to show people everything there is to see, moving them along at just the right speed. But be warned: go too fast and they won't take everything in; go too slow and they'll be bored.
Here are some ideas that have worked for me.
1. Don’t give overly specific feedback on code
A large part of technical mentoring is reviewing code. Unfortunately when some people hear “review this code please they reply “send me a pull request so I can make comments”. This then leads to line-by-line nitpicking, which is the style of reviewing that’s encouraged by code review tools like GitHub’s pull requests.
Contrast that with verbal, face-to-face feedback, when we’re more likely to be less detailed and focus on the bigger issues. Not to mention that with verbal communication we’re having a two-way dialogue that will undoubtedly generate more insights for everyone involved.
What’s the issue with commenting on style? Well, I think that design sense comes about through exploration, not from being given rules to follow. Recently one on my mentees had a question about this line of Java code:
new EventProcessor().process(event);
Their question was this: since the EventProcessor instance is only created to call one method, would it make sense to make the method static?
EventProcessor.process(event);
This is a stylistic question. There is nothing incorrect about the original code, and changing this method to be static would have no functional impact. What’s more, there’s a third option:
private final EventProcessor eventProcessor = new EventProcessor();
...
eventProcessor.process(event);
Which is the correct style? I’d rather not say. I prefer to let the mentee figure that out for themselves.
Design sense requires practice. Write 1,000 loops and 1,000 functions and you’ll eventually understand them. With my mentor hat on, I care if the code works and is “clean enough”, not that it is perfect or looks exactly how I’d write it.
Yes, knowing how to write perfect code is an important skill to learn, but it doesn’t need to be the teaching point of every exercise.
2. Walk the fine line between under-challenged and over-challenged
If you're workplace has a mentorship or apprenticeship scheme, you may be setting exercise work for your mentees. For optimum learning, each exercise you set should be slightly more challenging than the one before.
In practice this means that everyone you mentor should get a work plan that is tailored to them. A syllabus is helpful but it should contain enough opportunity for variation that you can ensure each mentee is suitably catered for. Going off-piste should be the norm, not the exception.
I do this by thinking through all the algorithms, programs and libraries I’ve written throughout my career and determining what would work for my mentee. As mentor you should make sure that you have a large variety of exercises to choose from, and always been on the lookout for more.
3. Estimation skills are crucial
When developers are at the very start of their career, they have little understanding of what they’ll be able to achieve in a certain period of time. At some point, however, they’ll want to feel in control of their skills. They’ll want to know with some certainty that they can deliver software within a certain amount of time. In order to get that sense of control, they’ll need to know how to estimate their work.
Get this wrong, and you could end up with developers taking on too much work and continually being overworked. Overworking is an all-too-easy trap to fall into. It’s important that junior developers learn to work at a sustainable pace. Good estimation skills can make that happen.
4. Learn to listen
The most important skill we can have as mentors is our ability to listen. Writing code is the easiest part of our jobs, and it’s easily taught. Listening to someone, understanding what they need, figuring out how to help them... well, that’s tough. When I’m with my mentees, my mental focus is almost always on how the mentee is doing emotionally. Learning to decipher what they are saying and to figure out what they are really saying. Are they energized? Are they struggling? Are they happy, frustrated, anxious, exhausted? What do they need right now to help them succeed?
I’m sure my ideas of mentorship will continue to evolve, and I’d be curious to hear thoughts from you as well, so please get in touch!
Top comments (5)
I just have to mention my objection at
This is a stylistic question. No, it absolutely is not purely about style.new Class().method()is also about resource use and the mystical "good code". One instance of such inefficiency here or there probably doesn't matter much, but letting it slip is going to lead to a widespread use ofInstead of
A systematic misuse of programming languages and referring to differences like that "stylistic questions" is going to lead you into having big issues later that are difficult to figure out because this kind of poor quality code is normal in your codebase.
Thanks for taking the time to reply. “Stylistic” perhaps doesn't clearly express my intent. I expect my mentees to have read enough that they’ll understand the language sufficiently to understand performance and efficiency considerations. But knowing when it’s better to choose readability over efficiency -- that’s the job of experience, not the mentor.
(Then there's the question of what does readability even mean, which again is something that I’d rather let them explore on their own without my influence.)
Sounds like a great way to mentor to me. As a learner, sometimes knowing the right way to ask a question can have a big impact on what I find in a internet search.
Are they energized? Are they struggling? Are they happy, frustrated, anxious, exhausted? What do they need right now to help them succeed?That's really interesting and cool way to look at the situation. I like to hear more about that, mainly because in all my time researching coding, I have never heard anyone talk in those terms. It's almost like you are analysing their mental health and using it to positively make them succeed. I'm struggling to explain what, I'm thinking, but I think you are on to something there. How did you come to this style of mentoring?
Tech has a culture of valuing product over people, but as soon as you reverse that thinking then all of this suddenly makes sense. For example, as in many office-based industries we have high levels of stress, anxiety and imposter syndrome. This is unquestionably detrimental so if you can work to avoid it, why wouldn't you?
The technical teaching is easier--books, tutorials and conference talks will all teach them that. As a mentor I need to be providing something that they can't already get from books.
Great Post Daniel!!
I tend to pay more attention to detail and some times I pay way too much attention.
Absolutely I agree, I will work on myself to adhere to that.
Thank you!!