5 reasons why hiring junior developers will help your senior developers
When I joined Mind Gym 16 months ago there were no junior developers on the team. There was a seniors only hiring policy in force at the time — I guess it was to ensure good quality code and fast delivery. In previous roles helping out junior devs and sometimes forming that “mentor” relationship was one of the more rewarding parts of the job. I missed that at first but concentrating on the technical problems we had to solve at Mind Gym gave me plenty to concentrate on.
That hiring policy changed a while back and about a month ago I found myself on a team with a junior developer again. The junior dev in question, Gulce Sakallioglu, is very smart and keen to learn — her fresh perspective and new tools and techniques will be valuable to the team. However, she does need time from the senior devs to explain things now and then.
I see how some might think that this process could slow progress down but actually it hasn’t. In fact, I’ve felt my motivation increase and have felt more fulfilled with work. This has led to me working a little faster on the project than I might otherwise have. I had forgotten the experience of helping someone learn the ropes and why it’s such a positive influence on a senior dev and the team as a whole.
After some reflection of my experience building mentoring relationships over the years, here are some of the reasons why:
💡 Explaining is understanding
Juniors are generally not scared to say when they don’t understand why you follow a practice or why the code is structured a certain way. When this happens, you’ll need to explain why. In order to explain the reasons why, you have to put your understanding of it in simple terms. Or if you don’t remember, you’ll need to Google and refresh your memory together. This means that you re-enforce your understanding of why you work in a certain way instead of taking it for granted, as well as spot areas for improvement.
🔨 Breaking down the problem
A huge Jira story could be very intimidating to a junior and leave them unwilling to take on what could be weeks of work bundled up into an “Add x endpoint” story. The best way to avoid this is to break that task down into manageable chunks, which can be handed out to developers on the team regardless of experience. This “breaking down” process can be a task the team does as a whole and become yet another learning opportunity.
⛑ Standards
Part of training a new dev is passing on the best practices for how to work within the team. Thorough PR reviews, well commented code, making decisions based on best fit (rather than what you’re used to), controlling your dependencies etc. If you’ve just told someone they have to do these things a certain way, it makes it kind of hard to cut corners yourself. There’s a feeling of wanting to set a good example which helps those standards remain intact.
👨💻👩💻 Pair programming
When pairing, you sometimes take the drivers seat and rattle off a new file or function. In this situation you have to be mindful of following the standards or practices you believe in. Don’t tell anyone but I’m more strict with myself writing tests first when I’m screen sharing. When solo coding its a little harder to resist the temptation to fudge something through without planning it and tidy up later. But that’s our little secret!
🏃 Motivation
Junior devs often work fast! They might make mistakes but they really want to see their work finished and in production. Yes sometimes they’re in a bit of a hurry and need extra input but if you’re not careful they’ll leave you in the dust and do twice as many Jiras. This is bad for the old ego and therefore creates a bit of healthy competition. You don’t want to be seen as a dinosaur whose obsession with TDD slows them down!
I’m glad we ditched that seniors only hiring policy. Creating a culture of learning in an engineering team can really speed things up, as well as create a more motivated team.
