How to be a good coach and set junior developers up for success

Do you want to enable your junior developers and have them become valuable members of your team? Well duh, you might say.

However a lot of more experienced developers who get a junior under their wing actually set them up to fail without realizing it.

In this article I will share with you some best-practices that I learned as a coach of multiple junior developers. The end-goal is to give you some tools that make it easier for you to turn new hires into valuable additions to your team.

Three things you need to know about being a coach

Before we go on to our list of best-practices, let’s take a look at a few things you should keep in mind about coaching developers.

1. It’s important

When I first started as a junior developer, there was another junior who started alongside me. Smart guy, motivated, etc… basically exactly what you want a junior to be. We got assigned to different teams.

I got assigned a coach that was very open to questions and who set time aside to help me understand problems. I felt good and enjoyed my job. My performance evaluations noted that I exceeded expectations.

On the other team, the other junior started shutting down about a month in. He was afraid to ask questions because he felt he was bothering people. That resulted in his work not being finished, which resulted in even more stress on his part, which eventually snowballed into him getting fired.

Was I a better junior developer? No! The other junior in my story is still working as a developer these days and is very successful. Turns out the other team simply had nobody who took on the role of coach and he was left to sink or swim. I am 100% convinced that If I had been placed in the other team, I would have been the one who had gotten fired!

2. It’s a lot of work

Being a good coach to a new colleague is a lot of work. In my experience, the first week or two I spend 90% of my time coaching. This means explaining the code base, discussing possible solutions, helping find issues, etc…

The reality is that new developers ask a lot of questions and need a lot of guidance. School might have taught them the basics, but they lack much needed experience. Luckily you have that experience in abundance.

As they get more experienced, the time spent on coaching decreases. But it never becomes zero. Keep this in mind and know what you are getting yourself into.

3. But it’s very rewarding

I love programming, I seriously do. But coaching people to help them realize their full potential? Making other people passionate about programming? Now that’s where my true passion lies.

Seeing someone grow and evolve into a skilled and professional developer, and knowing you contributed to that growth is a great feeling. The appreciation you get in return really feels like you made a difference for someone.

Even if you’re not as passionate as me about coaching people, or aren’t a ‘people-person’, remember it’s also important to have productive team-members. It’s nice not having to pick up the slack of other people. Being a good coach is how you get productive team-members.

5 best-practices that will make you a better coach

Now that we have established a few facts about coaching, hopefully you’re still interested in actually becoming a good coach yourself. Here are 5 best-practices when coaching new developers.

1. Clearly define expectations

The single most important item in this list of best-practices.

I recommend you take a look at Reddit, and specifically the ‘cscareerquestions’ subreddit. It contains all sort of posts, but a recurring type of post is one made by starting junior programmers. These posts usually talk about how they enjoy their job, find the project interesting, etc… But one thing bothers them, they are absolutely terrified that they are a burden!

If you compare a junior to other team members and the time you need to spend coaching them instead of developing that great new feature, you might agree that a junior does in fact feel like a burden on the team. However, you would be wrong. A new team member is an investment in future velocity gain.

The reality of software development is that it takes a while to get going when you’re joining a new team and a new project. It takes time to come to grips with the whole project and its rules, structures, design decisions, etc…

Instead of making them feel like a burden, tell them you expect them to come ask help if they’re stuck. Estimate tasks specifically with a junior in mind and set hours or story points accordingly.

You want them to experience small successes early on. These early successes will increase motivation and motivated people work harder.

Also keep in mind that setting and documenting these expectations also functions as a good tool to evaluate how everything is going. If things don’t work out, you have something to point to.

Finally, expectations evolve. You won’t expect the same from a fresh face compared to someone who has been at the company for over a year. So just as your new colleague evolves as they get more experience, so should your expectations evolve.

2. Plan ahead

Closely related to setting expectations, try to plan ahead what they will be doing. My personal goal is to have the first 3 weeks of work planned out for a new hire even before they start. This will not only help them know what is expected of them, but it will also unburden you.

For example, let’s say you are in week two and the new hire has a task they are currently working on. All is well, until suddenly you get the news that a server is down. You rush to fix the issue, but in the meantime the new hire comes to you and says they are stuck! You don’t have time right now to help them.

Luckily you planned ahead so they know what else they can work on. They pivot to a new task while you’re able to resolve the server issue.

If you didn’t have any tasks planned out, the result would be a junior who is stuck and doing nothing. This in turn is frustrating for you because you need to juggle the different responsibilities you have while under stress. Not to mention the project manager probably won’t be happy if they hear someone was ‘doing nothing’.

After the third week people usually become more self-sufficient and there’s no longer a need for a detailed plan of what they can work on. Usually in this stage they can refer to the task board and pick tasks that fit their skills and knowledge level.

3. Patience is a virtue

This is one I struggle with from time to time. When you have several years of work experience as a full-time software developer, it’s easy to forget what you did and didn’t know when you were just getting started.

You will get a lot of questions that might seem ‘dumb’ to you. Obviously refrain from calling them that. All questions are valid, since a question means a willingness to learn.

The only exception to that are questions that you have answered before. Someone asking the same questions over and over again shows an unwillingness to learn. If you’re investing your time to teach someone something, this is the opposite of what you want to see.

I always tell new hires that there are no stupid questions, except those that are asked twice. That usually gets the message across and makes them frantically grab a notebook and start writing. It’s better to be a bit harsh at the start, than having to let someone go down the line.

4. Have documentation

Oh the horror, documentation. The arch nemesis of many developers. Writing proper tests is probably a close second.

I’ll be honest here, I am not the greatest at keeping documentation up-to-date. It’s one of the things that I (and apparently many others) find to be one of the hardest parts of developing software. But having good documentation can be the difference between someone getting up to speed in a few weeks versus a few months.

So try to muster the discipline to make sure you have some up-to-date documentation in place. It will save you a lot of additional questions and also greatly lowers the bus factor.

5. Let them figure it out

A big part of being a good developer is being self-reliant. If something doesn’t work, you scour the edges of the known internet for answers to that terribly obscure error in your logs. You figure things out.

If you have a junior coming to you with every issue they encounter, and you proceed to answer every question in detail and solve the problem for them, they’ll learn less than if you actually let them find the answer for themselves.

The trick is providing just enough help so they can independently come to the solution. This is called the zone of proximal development and it’s one of the best ways to teach things to people.

Here’s an example. Let’s say someone comes to you and asks you why a certain bit of code isn’t doing what they expect it to do. You look through the code and notice an error in the logic.

Instead of just pointing out the error, step through the code and discuss what each step does. When arriving at the faulty bit of logic, ask them to explain what the code does. Perhaps they’ll now notice their mistake themselves (Rubber duck debugging).

If they don’t, give them a hint. Point them in the right direction, but don’t give the complete answer. Once they find the solution to the problem, I can promise you they will never forget it, and they will learn to be more self-reliant in the process.

Sometimes it just doesn’t work out

So you did all the above and still you feel like things are going sideways. Did you give it a fair shot? Do you feel like there is no evolution in the workload or responsibilities they can handle?

It can happen. Perhaps it’s a culture mismatch, perhaps they are just unable to do the work. It’s frustrating because you have invested a lot of time into the whole thing, yet it still went wrong.

Sadly, you can’t win them all.

However, I can assure you this is very rare. If you give people the tools to succeed, they usually will. So far I’ve encountered only one case where someone we hired was simply unable to perform at the level we needed, and we had to let them go. All the others (who had a proper coach!) had various amounts of success and were great additions to the team.