Supporting Junior Developers

When I think back to my time as a Junior Developer I think of one of the loneliest times in my career. I remember my first day as a Junior Software Developer and how unwilling the Senior Developers were to even verbally respond to my questions let alone guide me. I remember sitting there after being given the vaguest instructions imaginable and getting through my first day after making next to no progress. I remember approaching my manager almost through tears, thinking I was a failure, that I had nothing to show her as I lied by saying "I ended up deleting it all because it didn't work". Thinking back I'm sure she could see that I was lying. I'd like to say that they were teaching me a lesson or seeing how far I could get on my own but they weren't. As time progressed, it was obvious that the truth was that they just didn't care.

As I grew as a professional and as a person, I vowed to myself never to let a junior/lesser experienced developer on my team feel how I did for my first 2 years.

Software is a team sport. It rarely only takes one person to create software from start to finish without relying on skills from another discipline to make it possible. With this, a team with skill-level diversity and variation can help by bringing different ideas and perspective in the same way that a board can benefit from being comprised of different genders, backgrounds and ethnicities.

I have friends who work for companies that don't hire any junior developers at all which I find to be a bit of a mad, elitist and a narrow-minded thing to do. There is so much to be learned from Junior Developers and visa versa and the relationship is very symbiotic. They can often provide fresh perspectives and outlooks on problems and situations and sometimes point out the obvious overlooked solution. I recall being on my aforementioned nightmare first project with another Junior Developer and the disheartened look on his face when he was told to be quiet whilst the seniors discussed an issue. After they were finished he was 'allowed' to talk. His contribution was pointing out where the error was and I remember to this day it was 'caching'. It's always caching...

To get the most out of your team and juniors, you should aim to enable them to foster an environment that is safe and supportive, where they are heard and listened to, and you should aim to aid their professional and personal development in different ways.

Be available

This article isn't in any particular order but I've started off with what I think to be the most important point: be available.

Be there! Don't hide or ignore for long periods. Often 10 minutes of your time will be more effective than 4 hours of theirs if they're stuck. Software Engineering is hard and complex and for Juniors, asking for help or guidance can be scary. Establishing methods of communicating is important in effectively supporting others and it should be clear how this can be achieved. Regardless of what works best for you whether it's a Slack message, email or tapping you on the shoulder; it should be easy to reach you and for it not to be an anxiety-inducing experience. Your reaction and response to being reached out to could mean the difference between being part of their support network or not.

Of course though, sometimes you'll be unavailable as you may be in the middle of a problem, in a meeting, or just working with somebody else. It should be conveyed and understood that you will get back to them when you can but the main takeaway is that they know that you are there. Hey, they may even have worked it out for themselves by the time you get back to them!

Guide, don't instruct

It can be extremely tempting to simply tell the Junior team member what to do especially if you're busy. However, it should be remembered that instructing is a slower method of learning and although it might be a quick fix at that moment, these situations can occur more frequently. To more effectively support them you should aim to provide guidance and nudges. Teach them how to find the solution themselves! Ask provocative questions and provide nudges in the right direction whether it be where to find examples online, documentation, or describing techniques; you shouldn't do it for them.

A good rule to follow for this is to simply don't touch their keyboard. Ever. Like, not even slightly. Just don't touch it. Leave it alone. The keyboard is lava! You'll be a lot less likely to instruct if you don't drive. Be the navigator and enable them to arrive at the destination themselves.

Pair programming

Supporting Junior Developers can be very rewarding and pair programming is one of those methods that I find gives back to you in return. However, if this is something that you don't have a lot of experience doing, I'd encourage you to read up about how it works and how to do it effectively as there are many techniques and 'rules' that you can enforce and follow to get the most out of the experience.

I have quite a lot of experience onboarding Junior Developers onto my team and this is always my favourite activity to do. Not only does it allow them to collaborate without fear of not knowing some syntax or structure, but whilst 'driving' myself I have had so many mistakes pointed out to me. As more experienced developers we tend to 'solutionise' a bit more and think about where we need to be in a few hours rather than where we are now. This is all well and good, but sometimes putting a simple solution forward and iterating and refactoring can be just as beneficial as well as demonstrating good thought process. The input and frame of thought that Juniors can hold can be very beneficial to those more experienced and the relationship can be very symbiotic.

Have regular 1:1s

Have a chat! Do you both like hot drinks? Grab a coffee. There's a pub downstairs? Grab a beer. Whatever you choose to do, realise that you're humans at the end of the day and not extensions of the software that you're writing.

Regular 1:1s are a great way to ensure that Junior team members feel supported. Not only does this promote a positive and progressive relationship and environment but it allows you to identify areas that need attention so that their full potential can be discovered and unlocked. As mentioned before, software is a team sport and by helping each other you can succeed quicker as a team.

Establish a rapport, discover what drives them, how they learn best and talk about recent and past experiences. There are thousands of questions that you can ask to prompt and promote constructive conversation, but a few examples to get the ball rolling that you can ask are:

• What has gone well for you lately?
• What have been your biggest challenges and hurdles?
• What have you learned?
• Is there anything that you feel that you could be more supported with?
• Last time we spoke you said that <thing> isn't going too well. How is that going?

Setting goals to review and discuss at your next 1:1 can also be a good driver/motivation to progress and engage. You can use answers to the types of questions above to identify areas that need attention and if there is anything that you as a mentor can help with. As a final note on this point, this can be as formal or informal as you like. The main takeaway is that a regular point of contact to talk about things as a way of support can be hugely beneficial and listening to the perspectives of those lesser experienced than yourself can help you grow as a professional too.

Review code

I can't stress how important this is. Review, review, review! Whether your team works using trunk-based development or feature-based branching, reviewing the code of lesser experienced engineers can be a great way for them to learn through constructive feedback and also by validation that they've done the right thing. If you don't use a source control tool (you should be) for whatever reason then ask them to walk you through their code in person. Have them explain their reasoning behind decisions can also be useful to ensure that what has been implemented has been understood (and not just copy and pasted blindly from Stackoverflow...). Don't treat this as an interview activity though, it should be informal and a conversation - not a quiz.

An active and ongoing interest in what they're doing will help the feeling of belonging and will also develop their learning through support and critique. In addition to this, requesting their review on your code can be a great way for them to learn.

Be open to learning from them

Realising that this relationship is a two-way-street is key to getting things out of these interactions and you'll be a lot more likely to enjoy and appreciate them once you realise that they'll have things to teach you in return. Just because they're less experienced it doesn't mean that they will think of everything that you will have thought of! This will be easier for some than others, but leave your ego behind and acknowledge when they have taught you something whether it's passively/by accident or through a show-and-tell.

The fact of the matter is, Junior Developers will be more likely to be doing active reading and learning on the latest documentation than you so there is a higher chance that they have come across new information, techniques, or tips. Learn from them! If nothing else, learn how to support them by listening to their points of view, experience, and feedback on yourself as a mentor figure.

To repeat myself once again, this relationship is symbiotic!

Encourage and enable

This last point covers a slightly broader range of things that you can do to support the Junior Developers on your team. It's important to reaffirm that mistakes will happen and it's OK to do the wrong thing. Encouraging them to try even though it might be wrong is a fantastic way to learn as it provides a foundation and sometimes a springboard for discussion to arrive at the solution. I find myself explaining at times that the only reason I sometimes know the answer to a problem is because I have made the same mistakes. Teach them to turn each of these situations into a learning opportunity.

The level of safety a Junior team member feels to make mistakes, how enabled and supported they are to make their own discoveries, and the opportunity to be involved in bigger decisions will contribute greatly to their speed of growth and development.

Reflections

Creating software is very hard, full of nuances and many layers of complexity. This is a scary field for those just starting out in their software career and creating and maintining relationships of support won't just be beneficial to them, but to your whole team. Not only will you positively impact their development, but your team will move forward and progress faster.

Support, teach, and treat them how you would have wanted to be when you were just starting out and strive to be the role model that they too will hopefully become.