Becoming a better engineer by becoming a better mentor

Some dos and don’ts for supporting and coaching less experienced engineers

I’ve avoided the term ‘junior’ engineer here, as this post will be discussing thoughts that apply to many coaching situations. It also has a few connotations I want to avoid: when you’re pairing you’re going to learn things, even if you’re the mentor.

Software engineers spend a lot of time teaching and coaching. This is true whether they realise it or not, and if they really don’t, they should. We’re also typically not teachers, and there are some things we can bear in mind to get the most out of that time. Helpful tips to use whether we’re teaching programming to someone learning from scratch, coaching less experienced engineers in a pairing situation, or teaching a new stack to a seasoned developer.

I’m one of those engineers – I spend some time every week mentoring an up and coming engineer who started with no coding experience, I’ve volunteered as a teaching assistant at Ada National College for Digital Skills in London, and I pair and mentor daily here at Made Tech.

Things to aim for

Think about the desired goals of this mentoring/pairing session.

A goal will help keep both focused. Usually, this will be the feature or task you’re pairing on, but could be a learning goal like practising a technique or gaining confidence in a new technology.

Try to make mentees feel comfortable

Nobody will learn if they’re nervous, out of their comfort zone or overwhelmed.

Foster an atmosphere where either person can say ‘I don’t know’.

Most people will readily understand the need to ask their mentor questions, but it’s also really important to understand that your mentor is also human and doesn’t already have every answer. Sometimes, you need to find the answer together.

Foster an atmosphere where either person can ask questions or clarification.

Seems a given, right? But comfortable mentoring means being able to ask, for anyone. Comfortable mentoring is productive mentoring.

Foster an atmosphere where either person can ask for something to be explained again.

This is something I’ve noticed, at some point many people feel they can’t ask something because it was already explained. Feeling comfortable means feeling like you can ask for a repeat answer.

Seek feedback as a mentor.

Don’t forget this part, this is how we improve. Being a better mentor and coach means being a better engineer, as being able to articulate and share your thoughts will serve in more than just mentoring.

Communicate (especially important in a delivery setting).

Feels like another given, but communication is key. In a delivery setting, this means talking about the task and the context as well as learning and writing code.

Try to determine and work to preferred learning styles.

Some people learn from books, or from watching someone else demonstrate. Some people thrive on pairing, and others need to pad pairing time with solo research.

Some things to avoid

Avoid saying ‘just some code’, it’s easy, obviously etc

Another one that seems obvious, but I’ve caught myself slipping this one in at times. Takes practice to train yourself out of, but the single biggest thing you can do to improve the mentoring experience with programmers who are just starting out. It’s only obvious to you!

Avoid the temptation to do it yourself

There’s a couple of points I’ve seen here.I find it tempting to reach for the keyboard if someone I’m pairing with in a mentor capacity is really struggling with something chewy. Train yourself not to do it. A less obvious example is whipping up a quick PR to show what you mean, perhaps even to replace something someone else is working on. Often, I could spike something quicker, but this would be pretty demoralising, so it’s best to refrain.

Don’t refuse to write a little code to get things rolling.

I know what I just wrote is almost a contradiction, but something I’ve seen (especially with people very new to programming) is the hardest part is sometimes knowing where and how to start. I’ve had great success writing a few lines and letting momentum do the rest.

Avoid rushing.

This one is pretty applicable in all situations, but especially when working on a feature for production code. You can pair and rush, but nobody will get a lot of learning out of it.

Some things that have worked

• Pivot! A big thing in my mentoring is to experiment and find an approach that works for the mentee. If something is too complex/not interesting just try something else.
• Share your favourite learning resources – it’s also great for your own experience to revisit these.
• Learn fundamentals – Something particularly challenging for someone learning to code is that many materials assume you know how to use a terminal emulator, even things like project setup and installing dependencies may need some command line know-how.
• Workflow is as important as code – share what you know and what works for you around source control, collaboration and etiquette.
• Review progress and reflect – this one is especially important in mentoring people into programming careers, reviewing progress is a major motivator to push the next difficult part.
• Try to develop something mentees can be invested in/work on production code in a delivery setting – sounds self-explanatory, but personal investment in what you’re building helps motivate.
• Take proper breaks and if pairing, stick to pomodoros – it makes pairing slightly less draining.
• Be on top of pairing discipline – this isn’t just breaks and pomodoros, but also things like driver/navigator pairing discipline or even more esoteric pairing styles.
• Draw diagrams/whiteboard – Another one that seems a given, but a visual learning aid will help when explaining new concepts or architecting code.

Some things that haven’t worked

• Running before walking – Partly learn your fundamentals, partly don’t rush, but the final part is don’t dive into frameworks and complex programs before building and hosting a simple page!
• Remote pairing (for extended periods) – Hopefully my only controversial statement, it can work in a pinch and is fine for short periods of pairing on production code, but in a mentoring partnership try to get face to face interaction where possible!

Conclusion

I have written these points with pairing in mind for a reason – we believe pairing is the fastest route to knowledge transfer when mentoring, and effective mentoring is imperative to the health of a software delivery team. Being a great software engineer means making your team great, and sharing your skills effectively will strengthen that. A strong team delivers strong software!

About the Author