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!