Being a Junior software developer in your first job can be an overwhelming experience. You can feel like an imposter, even though you were hired on the strength of your limited experience and knowledge. It’s easy to feel out of your depth. The stress levels can be high, even if your team is making sure there is less critical issues on your workload and have padded the delivery time to make sure you can do the work. Isolation is a common feeling, even when your senior developers make it clear you can come to them when you get stuck.
Juniors are new to all this, they don’t know that seniors get stuck on problems and have to do their research too. You need to show them, if your stuck on a problem, ask them to pair with you, talk through where you are first so they understand. Then tell them flat, I’m stuck on this now, so let’s work on what the options might be! I need to do some research, would you like to help, let’s both explore what we can find online about this and then look at what we discovered together. Show them how you solve problems when you’re stuck, it might not be how they do it themselves down the line but you are letting them know it’s OK not to have all the answers straight away and showing them your way of dealing with that.
We all make mistakes from time to time, if you’ve pushed through a big bit of work and there are unfortunately some bugs that made it through to production, edge cases that weren’t caught in test, grab you juniors, tell them we’ve got some new bugs that made it through to live and unfortunately these ones are mine. Let me show you what they are and my thought patterns when I was working on this that lead to the oversight. Show them the processes that you have in place to deal with the bugs, show them it’s OK to make mistakes let them know that who made the mistakes is not important. What the mistake is and getting it resolved is what should be focused on.
As your juniors start to fly solo, make sure you support them, sit with them while they plan, ask hem leading questions about how they think they should approach the work set some check points together so they can discuss with you how the work is progressing and if they are hitting any road blocks. Discuss the designs with them, but let them take the lead, you can ask them questions about how styles might fit with the existing code, whether they can see any paradigms they can apply to their own work. Do not be proscriptive, we may want to have a nice consistent code base that looks the same in every component but you have to balance you desire for control against the personal development and learning of your team members. If there are a few components that use inheritance to share logic rather than because they satisfy an “is a” relationship, just let it go, it doesn’t hurt you or the code base that much. If you get on your high horse and start preaching the purism of object oriented design, you’ll suck the joy out of the job and clip the wings of those beneath you. You’re trying to build team members that can think for themselves, analyse problems and design solutions, not robotic extensions of yourself that produce your code for you. If there are some non standard applications of design patterns, they will start to creak under their own weight, logic shared though inheritance will snow ball and suck up more and more code and the tests will swell, grab the junior who wrote it and mention the size of the base class, see if they can talk through the single responsibility principle and the “is a” relationship and can spot the issue themselves as it becomes more apparent, get them to write the issue to cover the fix. You’ve taught them to spot a problem and plan the remedial action rather than just dictated a strategy.
LedSys LTD 