This post was originally published on my personal blog.

This post is probably a bit of a weird one. I generally don't talk about my soft skills as I hold the opinion that I am an awkward nerd who sometimes can't even keep English and German apart in his head and thus makes hilariously bad code switching a reality.

On the other hand, I've recently found myself doing a lot of mentoring during my hours at $BIGCO that I mentioned in my previous post about freelancing and the people I've been speaking with seemed to be into it.

Things I write here may be complete bollocks, but hey, read the first paragraph again and you'll understand why. I guess this is partly just for me to think things through.

Be patient with everyone

I don't know if you've ever noticed this with other members in your team, but many people seem oddly annoyed when approached with questions by someone. It may be because they dislike being interrupted by others during work, it may be because they don't like being bothered with someone else's problems. But it's always a bit sad to see when someone has a question and the person they ask rolls their eyes or sighs as they get up from their table.

Hence I always, always, always try to be patient. I've had many people come to me for a question that took me all of a minute to show them the answer to. They got unstuck and could happily continue their work and I didn't lose any critical amount of productivity in mine. If a question in your team pops up a lot, write it down on an FAQ page.

And if you ever find yourself losing your train of thought, go and read this post by Swizec. No one will hold it against you if you take a few seconds to write down stuff.

Give them tools to solve the problem

One thing that can be nice to do is to not point somebody directly to a solution unless it's critical to your deadline. But if you have leeway in your project try and show them how they can find a solution themselves. They don't know how to get started with checking where things go wrong in their program? Teach them how to use breakpoints to step through their program! They can't figure out why their flexbox is behaving weirdly? Show them a site like flexbox.help let them describe their goal to you and let them click through it while explaining it to you.

If they really ran into something bigger they'll come back and ask for help again, but if they can figure it out themselves that feels like a huge win that they had independently of you. It gives a sense of confidence and independence.

So show them how to get there, but don't just point at the screen and tell them, they should have, obviously used justify-content: space-between instead of justify-content: space-around. Let them have their own wins.

Pair programming can help a ton

This is of course dependent of the type of person you're dealing with, but sometimes of people feel a lot more confident when pair programming. At times it already helps if you're the duck for their rubber duck debugging. While they speak out loud and explain the code to you, often times things will click in their head.

So if they're open to it and you have a few minutes, sit with them. Let them explain their code, walk through it with them. Sometimes the thought of someone having your back is all that is needed.

Listen to the individual

Of course, all of this varies from person to person. Junior devs that joined your team a week ago will most likely need more hand-holding than one who joined two months ago. Some people don't like somebody looking over their shoulder while they code, and that's fine too. For what it's worth I'll fumble through a docker run command if you just stand their and watch me.

Each person is different and each one requires a different approach to mentoring. But these are some things I found useful in helping others learn. Maybe you can find some use for yourself.

And above all, when a question seems trivial to you but insurmountable to your junior always remember: Once upon a time you were new to programming as well. ;)

Enjoy!~