Secrets of mentoring junior software engineers

Mentoring junior programmers can be a daunting task. Senior developers usually aren’t efficacious mentors. Because of that, it is crucial to set clear expectations and focus on the high-leverage activities so that the mentee can become productive as quickly as possible.

Table of Contents

1. What kind of mentoring?
2. Why are we mentoring junior developers?
3. Don’t be overprotective
4. Don’t be overwhelming
5. Tell. Don’t show
6. Allow them to learn
7. Keep them motivated
8. Teach them good practices from the start
9. Who would be the best mentor?
10. How will the mentors grow?
11. What to do next?

This article will offer some advice for upskilling junior software engineers.

Initially, I was going to focus only on mentoring in data engineering teams, but after writing the text, I realized there isn’t much difference between mentoring data engineers and other software engineers. Every team training new developers faces the same issues.

What kind of mentoring?

Gergely Orosz distinguishes between three kinds of mentoring processes. Today, we are not interested in onboarding - I have an article about it on my other blog. Also, we won’t discuss any formal mentoring process with regular meetings, intermediate goals, and formalized mentor-mentee relationships.

Instead, we’ll focus on the mentoring happening informally within the engineering team when a junior engineer joins the group.

Today, I’m particularly interested in technical mentorship, helping junior developers get familiar with the code base, making them self-reliant, and giving the new hire advice about working in a software development team.

Why are we mentoring junior developers?

In short, we mentor junior developers to help them become productive and self-sufficient as fast as possible.

Of course, in the case of software development teams, being self-sufficient doesn’t mean we don’t need any other team members. It means the engineer can pick a task, procure all required information from other people, solve the problem, and document the solution well enough so another person can continue their work.

We won’t focus on the promotion process. The hints I want to give you will increase the junior’s technical ability and definitively help them get promoted to the next level in the company ladder. However, that’s a long-term goal and requires fulfilling many non-technical requirements. Also, the process varies between tech companies. It isn’t the problem we are solving today.

Don’t be overprotective

The first problem I see on many teams is shielding the junior from doing any work where they could fail in any way.

Don’t do that! Failure is required to learn.

Of course, we want to be sure the junior developers can fail safely. We won’t allow them to modify production data directly. We won’t let them deploy untested code in production. We will thoroughly review their code. However, don’t prevent them from breaking anything in the test environment (especially if they can have a separate test environment just for them).

Junior developers are not endangered species needing protection!

Don’t be overwhelming

It is enough for a senior developer to answer questions and do regular pair programming sessions with them. However, be careful not to overdo it. Don’t constantly sit behind their back and look at their screen. Don’t be creepy.

A good mentor should first and foremost be giving respect and building a good relationship. Don’t be too nitpicking during the code reviews. Don’t be a person who spends three hours explaining why their variable naming method is superior (Seriously, I have seen something like this. Unfortunately.)

Don’t insist on pair programming if the junior developer feels uncomfortable working this way. Listen carefully to what they say and don’t give them “good advice” if they don’t ask.

Your goal is to make them feel as if they started their career path in the best company in the world.

Nothing breaks a mentoring relationship as fast as a know-it-all who imposes their ideas on others.

Tell. Don’t show

We get it. You could do the task in 30 minutes, and the junior developer has been struggling for almost five. That’s why they are the mentees, and you are the mentor.

Don’t take over the task. Be helpful but please refrain from showing off. You are there to teach, not show that you are better than a junior developer. We know you are. If you weren’t, you wouldn’t be here.

Allow them to learn

If we continue giving junior engineers only the simple tasks, that will be all they are ever able to do. The same happens in sport. What’s your favorite sport? Let’s assume it is running. You won’t run a marathon if you run 5 km runs every day. You need to increase difficulty gradually!

If a junior engineer gets only the trivial tasks (probably because nobody else wants to do them), they won’t learn anything. If you allow that to happen (and the junior developer can’t learn in their private time), after six months, you will still have a junior developer who needs constant supervision.

Because of that, the difficulty of tasks performed by the junior engineer must occasionally increase.

Keep them motivated

As I said, the difficulty must occasionally increase. Not constantly! Not every day.

Imagine being a person who gets a task that is slightly above their ability every day. Just barely, but it happens every day. Every day, the first thing you think in the morning is, “I have no clue how to do it.” It looks like a perfect way to trigger the imposter syndrome.

That’s why I think the task difficulty for junior developers should vary. We want them to learn, but we also want to keep them motivated and satisfied with the work.

Once in a while, they should see what colossal progress they made by getting a task that seemed difficult three weeks ago, but now they can do it quickly.

That will build their confidence. After all, you don’t want a developer who is scared of software, do you?

Teach them good practices from the start

Don’t let them learn bad development habits and practices. It would be a waste of time if the junior engineer learned to hack the code together without any automated tests and later was told to learn to test.

Even if your company’s development process is not ideal, teach them how things should be done.

I insist on teaching test-driven development as soon as possible.

First, the junior engineers will need to figure out how to turn a ticket description into the expected behavior of the code. TDD is not a significant effort at this stage. They have to do it anyway.

Second, TDD gives them a safe environment to make mistakes. They have fast feedback when they make a mistake. Show junior developers how to write unit tests well and use the continuous integration server.

Also, junior engineers should learn to write and update documentation. It makes no sense to let them write the code and have someone else edit the documentation. It is even worse to use them as an excuse to have outdated documentation.

Who would be the best mentor?

The entire team. Don’t pick one person as the mentor for the junior engineer.

In a data engineering team, the engineers specialize in different skills related to data engineering. Even if you think of them as data engineering generalists, there are things they prefer to do. Let them teach those things.

There will be someone who can explain everything about databases. You may have an engineer who does the most helpful code reviews because they focus on code performance or any other topic the rest of the team struggles with.

Maybe you have an engineer who seems to be a great mentor because they speak at meetups or teach workshops. Don’t let them be the only mentor. The others should do it too. Not only because of the junior engineer, but mentoring will allow them to learn some soft skills and give them an opportunity for professional growth.

How will the mentors grow?

The mentee is not the only person learning while mentoring.

Mentoring is the best way to figure out what you really know and what you only think you do. When you have to explain the concept to someone less experienced, all gaps in our knowledge are immediately visible.

It may be uncomfortable for many developers, but don’t panic. Those gaps are visible to you. The junior developers won’t notice them.

You will learn a lot while teaching. Of course, only if you make an effort. It is easy to say some general statements about the topics and forget about what you didn’t understand well enough to explain. However, I encourage the senior engineers to research the answer. Not only will the junior programmer benefit, but so will the mentor.

Last but not least, mentorship is an excellent opportunity to grow a career within the company. Senior engineers who train new hires and junior developers give the company a tremendous performance boost. Every time you train a software developer, you should congratulate yourself on doing a great job. Most engineers don’t want to do it. That’s why a mentor stands out from the crowd of developers in all tech companies.

What to do next?

If they have time to read books, or (better) if you can give them some reading time during the working hours, pick a few software engineering books they should read.

To ensure they don’t waste time, tell them they need to summarize every chapter to the entire team (or junior engineers from other teams).

Which books should they read? It doesn’t matter. If they haven’t read many of them already, any book will help them grow. That being said, I suggest being careful with design pattern books. Software developers have a strange habit of applying all of them as soon as they learn about design patterns. It would help to have a senior developer do the code review and explain when to use those patterns in real life.

Soon, the junior engineers will be as productive as the rest of the team.