7 Tips to Mentor Junior Developers More Effectively

How do you take an energetic, scrappy junior developer and help them grow into a talented senior?

It's an art, and an daunting one for individual contributors making the first jump to the management track.

But with a little empathy, and by tapping into your own memories of being fresh-faced and lost in a terrifying codebase, you can help your junior colleagues feel like they've landed the job of their dreams.

Over the years, I've gathered a list of effective tips to help you – and them – get the most out of mentoring. In a few months, they'll be contributing to your codebase like a pro. And in a few years, they'll remember who helped them launch their career.

1. Stop the backlog horror show

Let's look at the classic junior developer fodder that I know you have in your backlog:

• Rename some variables
• Fix some janky CSS on tablet-sized screens
• Add a new linting rule
• Close a gap in the unit test coverage
• Update the docs
• (The list goes on...)

I mean, snore. These are terrible tasks for juniors. They're terrible tasks for everyone. It's the most boring work, and we habitually push it off onto new joiners because we don't trust them to do anything else.

This kind of grunt work should be a shared misery – what can't be automated should be divvied up among the team.

Listen, when you get a fresh junior, you have a brief window of time to inspire them. When you get a recent CS grad or bootcamp alumnus who hasn't yet been crushed by the weight of unmet expectations, the last thing you want to do is appoint them "code janitor".

Give them a real project. Ideally a feature. Stimulating but self-contained. A problem that requires a little software design. Something slightly intimidating, on the understanding that they have unlimited, no-stupid-questions access to you and the rest of the team for help. Make them feel like they're contributing to the product as an honest-to-God software engineer.

We rarely have more energy and will to contribute than at the start of our careers. Don't smother that spark with drudgery.

2. Give them just enough room to fail

If you give a junior a proper project, they're probably going to make a total hash of it. Great! Plan for that. That's part of the point.

When assigning the ticket, sit down with your new comrade and explain all the ins and outs of the problem:

• Current state: what the existing code does
• Historical context: why the code is the way it is
• Crystal-clear requirements: what needs to be done, in such detail that a non-engineer would be able to perfectly understand it
• Suggested starting points: where to look in the codebase, what to read, what to Google.

Then, let them go. Arrange a catch-up for later the same day to show you whatever it is they've done. This is critical – never let a junior drown in their own confusion for fear of appearing stupid. Assure them that you'd rather see a total mess in four hours than something sort-of working in four days.

Let them do what software engineers do: read code, read the docs, Google around a bit, make a mess, and then clean it up. We never forget what we discover by ourselves.

3. Ask, don't tell

When your junior developer comes back to you with their first attempt at a real project, it will probably be bad.

Do not, under any circumstances, deliver your feedback in the form of PR comments.

You may not fully appreciate the gulf between your mental models and those of a junior developer. Your vocabulary is different. You have intuitions about the codebase that will seem to come out of thin air. You will find yourself reaching for concepts and metaphors that have no meaning in their fresh, uncluttered minds.

Instead, go through their code together, in person or on a video call. Ask them to explain their thinking. Gently question their assumptions. Ask how they would expect their solution to perform given certain edge cases, or important scenarios they've overlooked. Clarify any requirements that have got lost in translation.

Only once they're fully stumped should you offer your own suggestions. Think aloud, revealing the thought process that led to your solution. Specify the benefits of your approach, such that they'll learn to reach for these patterns automatically over time:

• "This way, we can add new features without having to change this code"
• "By factoring this behavior into its own class, we can test it in isolation"
• "By using an interface here, we can swap out the implementation later".

Demonstrate once, then let them go away and finish the rest by themselves. Repeat as many times as necessary to achieve true learning.

4. Deadlines? What deadlines?

Don't rush juniors. Just don't do it. Over the course of their career, rushing in the early days will lose them months of productivity in PR revisions, hotfixing bugs of their own creation, and self-doubt.

You will get so much more value from training a new developer to do things well than you will from getting a feature out a week earlier. The first time they do things "The Right Way", it will be slow and painful. The second time will drag too. But by keeping the pressure off until they're ready for prime time, "The Right Way" becomes muscle memory. Smooth, effortless correctness.

Think of a junior developer as a young pianist practicing scales. Telling them they've got a gig at Carnegie Hall next week is not going to help them play.

5. Own your crappy code

In every new role I take on, I always hope that some intellectually rugged, self-effacing super-dev will look me in the eye and tell me what parts of their codebase are total ass.

This is especially important for junior developers, who love copy-pasting even more than the rest of us.

If you have poisonous code that must be contained, tell them what to watch out for so their impressionable minds aren't corrupted by the terrible examples of developers past.

An important side-effect of calling out the warts in the codebase is in helping junior engineers understand that seniors are fallible too. However bad their code might be, they can take comfort in the fact that you've written worse.

Better still, if you have gold-standard code that fills you with pride to behold, show them where the bar is! Have them study it and grow wise.

6. Find out what they want

Let's be honest: developers do not have a strong track record for empathetic, expressive people management. The kind of management in which team members are treated as full humans with hopes and dreams rather than "development resources".

If you're the kind of manager whose primary focus is on getting the next feature out of the door, tear your eyes away from Jira for a moment and do this simple exercise with me.

At your next one-to-one, ask your junior developer what they want. Out of their current role. Out of their career. Out of life.

Then, set out a plan for how you will personally help them get there, within the constraints of your role.

What does that look like?

If they come to you with a dream of becoming a CTO, within the constraints of your role, you can direct them towards the resources and opportunities that will, as a starting point, lead them towards the management track.

You can provide reading lists, recommend courses, introduce them to other leads and more senior figures in the business. All of this will help them understand what their goals actually mean in practice. That might make them change their mind, and evidence-based mind-changing is to be celebrated.

You can allocate projects within your team that play to their ambitions, such that, when it comes time to assess promotions or they move on, their CV tells a story of a talented junior developer who has the makings of a great manager.

Notice that I said "move on". Career development isn't about career development at your company. Would you want to be limited like that? It's about giving your team member the tools to make an unqualified success of themselves.

You always hope they won't leave, but your primary task is to make a rockstar developer out of them. Because those are the people you want to work and keep in touch with.

What doesn't that look like?

Unless you're the CEO, you're limited in what you can promise a direct report. If a promotion or pay rise can't be guaranteed, make it clear to your junior that, while you'll fight their corner, nothing is set in stone.

If the type of role they want isn't available at your company, be honest about that. Never keep someone on the hook knowing that the work they're dreaming of doesn't exist in your organization.

Instead, make it clear how their current role will advance their skills in a way that will help them fly the nest when it's time.

All of this requires you to care about your direct reports on a personal level. If that's not you, then get in touch! I'll happily help you develop into the individual contributor you were born to be.

7. Show them the deep end

As we grow as engineers, we work our way up from short scripts to applications to system architecture. Today, lead and staff-level engineers are expected to understand and design distributed systems of comical complexity. It takes years of experience to do this well – so you'd best get new developers started as soon as possible.

I don't expect junior developers to contribute to architecture discussions, but I do want them in the room. They should be immersed in the language of distributed systems from the outset, hearing the trade-offs that get made at the highest level of software design.

Encourage them to ask questions, and support their learning with resources like the seminal Designing Data-Intensive Applications (Kleppmann), Software Architecture: The Hard Parts (Ford et al.), and System Design Interview: An Insiders' Guide (Xu).

That last one isn't just for interviews, but offers a wealth of insight into many of the classic problems of system design.

A well-stocked office library (or corporate O'Reilly Safari subscription) is rocket fuel for a junior developer's career, particularly if you can sanction time to read on the job.

Once more from the top