What a junior developer needs from a team
Head of Training at Makers Kay outlines how you can get more out of your junior developers
To succeed, a junior developer needs:
- High expectations
- Empowerment & responsibility
- A failure-tolerant environment
- A steady stream of challenging work
- A mountain and a map
- You and your team
High expectations
The number one reason junior developers stall is that not enough is expected of them.
You may feel the tendency to lower the pressure on them in order to reduce stress, which is understandable but misplaced — people usually relish a challenge as long as they do not see the consequences of failure as disastrous.
Instead of this, you may communicate with words and actions this message: “This work is challenging, but I believe you can do it.”
With judicious support, you can gradually increase the scope and complexity of the tasks your developer can undertake.
If you genuinely feel like you can’t trust your junior developer to take on more challenging work, there may be a larger problem to be addressed. If so, get in touch and we’ll figure it out together.
What you’ll see if this is going wrong: stagnated growth, constant questions about technical detail, frustration from the developer.
Empowerment and responsibility
You may have worked with inexperienced developers who complain of many problems in their project, team, environment, or even manager! In many cases these are reasonable, but the thing to watch for is when people start to use these to explain why they are prevented from doing good work.
When people attribute their own lack of success to things they can’t control, it’s not rational for them to try to grow — so their growth stalls. It’s essential as a manager to guide your junior developer to take responsibility for their own success, and to empower them to overcome obstacles in their environment.
Let’s say for example your developer is working on a legacy codebase without tests. They might say “I’ve been stuck on this ticket for days, this codebase is terrible, doesn’t have any tests, and there isn’t enough support here for me.” — the implicit message is that the codebase and the team are the problem, not the developer’s current low skill in working with legacy code.
You might respond with a message like:
“Yes, it’s definitely a tough codebase — but I’ve seen good work from you, I believe you’re the right person for this ticket, and that you can do it/ [high expectations]
“Let’s talk about what you’re finding difficult — I know you’re good at writing tests and it’s one of the reasons you’re here [responsibility], so let’s find a way you can start using tests here to help with the legacy work [empowerment]. In fact, there’s a book called Working Effectively With Legacy Code that focuses on using tests!
“I know it can be tough to reach out to ask for support from me and the team, and we might not always get back immediately, but we really do want you to! [responsibility] Next time you’re not sure how to get it, message me and we’ll figure it out. [empowerment]”
By the end of this message, it’s clear both that it’s their job and in their power to succeed at this task, with your support.
What you’ll see if this is going wrong: complaining, lack of ownership.
A failure-tolerant environment
At one time or another we all make mistakes. When this happens it might have big or small consequences for us. If it has small consequences, we alter our behaviour in small ways. If it has big consequences, we probably significantly reduce the number of risks we take.
For a junior developer, almost every task is a risk. If failure has big consequences, they will take work reluctantly, check with seniors regularly, and try to avoid taking responsibility. It is therefore important that the consequences of failure are small, or at that large failures are unlikely given the developer’s current skill.
This presents somewhat of a paradox — how do you shield a developer from the consequences of failure without compromising your high expectations? You can’t always assign blame to the environment either, because this will reduce the developer’s feeling of responsibility.
The solution lies in noticing that junior developers mostly worry about getting fired or losing the respect of their team. The important thing is that know you still believe in them even when they fail.
You might start by communicating with words and actions: “everyone makes mistakes, takes longer over tickets than they hoped, gets frustrated — the important thing is to learn from it”.
You might even go further and explicitly reward failure. Sometimes I have said that if someone isn’t failing regularly, they’re not pushing themselves hard enough. I have often, when someone has gotten stuck for days over a tricky problem, become visibly excited and explained how good it is that they have the opportunity to discover why they got stuck and grow from the experience.
Just as it is important not to publicly shame people for failure, it is equally important not to be embarrassed about it. This communicates that failure is embarrassing. Consider being open about your own mistakes! It is likely they have been some of the most powerful growing-moments in your career.
What you’ll see if this is going wrong: developers silently failing for days without telling anyone, reluctance to take on challenging tasks.
A steady stream of challenging work
You may feel a sense of relief when your junior developer is up to speed and can take on a certain category of tasks with ease — the hard work is over and you can step away. I’m afraid your job is just beginning!
Challenge is essential for growth. At the same time as some tasks will simply be too difficult for your developer to get anything out of, many tasks will just be too easy.
This will not be particularly surprising, but the challenge for you comes in trying to manage your team to get work done. Easy tasks have to be done too, and more challenging tasks require support you may not have the resources to provide.
In the case of the easy tasks, you have an excellent opportunity if you are trying to grow your team. If there is enough easy work now to support a new junior-level hire, consider doing so. Your current junior can onboard the new junior. If your team is fully staffed, consider what it would take to automate or at least make quicker the easy tasks — such work can provide extra challenge and increase the velocity of your team.
In the case of providing support as the junior takes on more challenging tasks, you have to weigh up what you will invest on this support vs the return you will get back in the form of your developer now being able to perform more complex tasks. In some cases you may not be able to spare that senior time, but in most cases it is a sound investment.
If you genuinely feel like you can’t trust your junior developer to take on more challenging work, there may be a larger problem to be addressed. If so, get in touch and we’ll figure it out together.
What you’ll see if this is going wrong: bored junior developers, fitting themselves into niches or doing challenging but low-value work, developers leaving within a year or two.
A mountain and a map
That is: a compelling destination and an understanding of how to get there.
Many employers fall into the trap of assuming developers care mainly about technical matters, and not about the strategy of their company. In my experience, this is true only when the company fails to communicate its vision internally — developers fall back to caring merely about their own skill. It is no surprise, then, when it suits them to leave.
Developers, like the rest of us, want to come into work every day and believe that what they are doing contributes to some wider purpose. Even if the purpose is just making money — you will hear developers begrudging work that they don’t believe will do so.
So that’s the mountain — a compelling purpose.
The map is the developer’s greater-than-normal need to understand how the business intends to achieve its objectives. They need this because developers are always making judgements based on guesses about the future — whether something will need to change or not, and who will need to change it. If the business is likely to expand into Brazil in the next 5 years makes a difference, compared to say New Zealand (will currency need to be flexible? how will translation be handled? is collaboration across timezones likely?)
Someone they can rely on to talk about the strategy for software engineering in the organisation, all the systems and how the connect, and their larger purpose for the customers will help them make much better decisions.
It also helps them connect the frustrating minutiae of software engineering to the larger ‘mountain’ purpose. Developers who see why their work matters write better software. Sometimes corners can be cut in the interests of speed-to-market, sometimes reliability is paramount — developers who understand the strategy make these micro-strategic decisions effectively.
This is all especially important to juniors because their work is disproportionately more challenging than it is for other people. They need to feel motivated because things are harder for them!
What you’ll see if this is going wrong: technical decisions that seem out of touch with reality, dependency on seniors or managers for context, and a counterculture of low quality work, justified by it not really making much difference either way.
You and your team
All of the above takes time and effort to maintain. That starts with you.
Well crafted teams do a good job of maintaining it, but someone will still need to be around to talk them through the high expectations, help them understand how they can become responsible for the quality of their work, reassure them when they make mistakes and advocate for their having challenge in their work.
At Makers, we spend a relatively small amount of time working directly with developers — and providing too much senior support can form dependency — but a certain amount of time with experienced developers can be transformative.
Having your experienced developers be ‘on-call’ for interruptions at any time has obvious drawbacks, and may not be best for the junior either. It puts them in the relatively disempowered position of asking for help when they believe they can’t progress. Instead, consider:
- If you’re not already pairing regularly, setting aside an afternoon or two per week for juniors to pair with more experienced developers. This allows your senior developers to schedule in suitable work, and make sure they don’t get derailed at other times.
- ‘How I would have done it’ sessions. Set up a time for a group of junior developers to meet with one or two experienced developers, and have one of the juniors bring a ticket they recently worked on. Given this, the senior can non-judgementally demonstrate how they would have gone about solving the problem. This helps junior developers learn new ways of working and trains their judgement.
- Pull requests as questions. Propose that when your junior developers get stuck, instead of walking over, they make a pull request with their work as far as they could get it and a clear elucidation of their problem. This can fit relatively neatly into an existing code review process, and is especially good for distributed teams. They may even fix their problem in the process of explaining their question!
When junior developers do get stuck, it’s worth ensuring your team take the time not just to fix their problem — but to figure out why they felt they couldn’t proceed and help them resolve that. Doing this systematically results in more productive discussions and more independent junior developers.
What you’ll see if this is going wrong: frustrated junior developers, unsure where to go or how to access support, and lots of apologetic interruptions.
