With fresh new devs popping out of CS programs, bootcamps, and self-taught paths every day, chances are you are going to end up working with one. Maybe you're dreading it because you fear lots of hand-holding in your future, or maybe you're stoked because you get a chance to pass on your well-earned wisdom. Either way, there they are, and it's in everyone's best interest that they succeed.
I have been lucky to be extremely well supported at my first dev job, but I know that's not always the case. If you're looking for some ideas for how best to do the same for your new junior, you're in the right place.
No matter what kind of education they are coming from, they are walking into a completely new environment with more real consequences for the code they write. They are likely feeling overwhelmed, confused by the codebase, intimidated by the expertise around them, and pressured to succeed. There's a lot going on and this transition is not easy, so try to treat them with compassion.
They probably have questions. Likely hundreds. They might be afraid to ask them, or to ask too many and take up your time. They will greatly appreciate you taking the time to ask how they are doing and if they have anything you could help them understand.
You're very busy and important, so it might slip your mind to go and check in on the juniors. So get them to come to you by putting office hours up on your calendar! This is a great practice especially if you are a senior dev or have a title like DevOps, SRE, Product, or something similar that I for one was completely confused by at first. You will probably get non-junior visitors as well and you'll see how valuable your time can be to your coworkers.
Whether you've been a developer for 2 months or 20 years, one of the great things about this field is there is always something new to learn. If you know there's something you'd like to learn, a Udemy course you'd like to take, or just a topic you need to brush up on, invite them to join you. Being new can often feel like everyone knows everything and you know nothing, so seeing that more senior developers are learning too is a huge relief.
This is something junior developer hear ALL THE TIME. If you don't know, ask. We will continue to do so, but sometimes it can be intimidating to be the only one asking questions. If you are a more senior dev, asking a question in a meeting not only gives you the answer (hopefully), but builds a welcoming environment for everyone to feel comfortable doing the same.
They might write some code that you see and think to yourself "My goodness what hot garbage is this?!", but know that they likely spent hours or days struggling to find a way to make it work, and they're proud of that feat. You will of course have time to (see below) give feedback to help them improve the work, but show them that you see how much effort they put in. Personally, I know some of the easy tickets that take me 3 days to complete could likely be done in an afternoon by a senior dev, but I appreciate that the team makes me feel that I add value. It makes me want to work harder to contribute more next time.
Of course it's important to be supportive, but that should go hand in hand with helping them improve. With every code review, you have a great opportunity to give constructive feedback. This will not only help their code be better next time, but you lay groundwork for the standards and expectations that are specific to the company. Feedback is necessary for their growth, just try to make sure it doesn't come from a place of frustration, impatience, or superiority.
There are going to be tasks that are way over your junior's head to the point where they might not even know where to start. Instead of letting them attempt and fail and get stuck and frustrated and doubt themselves, this can be a great opportunity to pair and let them watch your thought process. You can even put them in a position to drive while you point them in the right direction, which depending on their learning style may help them understand even better. Ask what they're comfortable with.
Personal experience - this was one of my favorite things that I was invited to do in my first few weeks as a junior dev. Someone suggested a few of us, ranging in experience, read Clean Code together and meet every week for coffee to chat over the most recent chapter. Not only was it a great way to discuss best practices for our code, but it gave me some allies at the company right off the bat. It's also nice to walk away from staring at your screen for a bit sometimes.
We know we might have learned how to do this in school, or you might have told us once before where the answer was but there is A LOT sloshing around in our brains right now. I have it on good authority that even more senior devs have to google the same thing multiple times, so try to be patient with us as we learn what you may consider to be the basics. Remember, you were a junior once too.
Big week for me: I finished writing my eBook in French about React, and I couldn’t be prouder. Eight months, and it was not easy, but it’s so worth it. In this post I wanted to expose a few thoughts about what happens when you write a technical book.