One of the most rewarding parts of my job as a tech lead at Ameriprise has been mentoring a team of junior developers. With my current project wrapping up, it seems like a natural time to reflect on what I’ve learned about mentorship, specifically creating a healthy environment for learning, common soft skill/process pitfalls junior devs fall into, and several things that you as a mentor should be working on as you help your devs get up to speed.
Import disclaimers/notes:
- Being a good mentor and/or tech lead is a topic worthy of a book or four. This article is primarily focused on mentorship in the first six months or so after you hire a junior dev.
- Thanks to my manager’s adept hiring instincts, I’ve been lucky enough to work with some smart folks who just happened to lack experience as software developers. This article probably won’t teach you how to compensate for a lack of quality hiring. If you need help with your interview process, check out this post.
- Mentorship is not a skill I’ve mastered, so if you feel like anything here is worthy of alteration or correction, please reach out: lnagle@gmail.com
A Healthy Environment for Learning
First of all, if you’re in a position of seniority, it’s essential you understand that you are central to shaping the environment in which your junior devs work. The three things I’ve found most important to foster around my team are:
- A focus on growth. This means that knowledge and technical decisions are shared across the team, people aren’t pigeonholed into certain kinds of tasks, and you challenge your junior devs to take on new tasks that stretch their abilities while reminding them that you’re around to help them when they inevitably get tripped up.
- Psychological safety. Everyone on your team should feel comfortable exposing their ignorance. Because new hires are often very ignorant (particularly in regards to your existing code/systems), you should be fielding a ton of questions. If they’re afraid to ask you- and they almost always are, starting on day one- that’s going to seriously hamper their progress. If you make them or someone else feel dumb because they don’t know something, it won’t take long before they start prioritizing not looking dumb over their own learning, at which point you’ve effectively shot yourself in the foot. This dovetails nicely into my third point.
- An obsession with quality. I remember my very first PR at my first job as a software developer. It was a debacle, with dozens of comments pointing out all manner of issues. I certainly didn’t feel good, but the silver lining was that it was readily apparent based on the tone of the comments and the conversations I had with my coworkers that in their minds, I was not my code. Instead of criticism and judgement, their PR comments came from a deep care for code quality and because they wanted me to learn all the ways that I could make my work better. Encouraging the same quality-first attitude (aka craft mindset) in your own junior devs is pivotal, especially early on.
Common Soft Skill/Process Pitfalls
As obvious as it probably seems to you, software development is not all about coding, and the junior devs that I’ve worked with have all made some of the same non-technical mistakes in their early months. Knowing about these pitfalls ahead of time can help you either prevent them or at least correct them sooner.
- Not asking questions. No one wants to look stupid or incompetent. It makes sense then that most people are afraid to ask questions when they start their first engineering job. They need to be repeatedly encouraged to both ask for help and do it sooner than they think they need to. I’ve had good luck proactively darting off a quick message each morning when I get in asking how the previous day went and if they have any questions (sort of a 1-1 stand up via email/slack). That practice naturally tapers off once you’ve established enough rapport and they are comfortable being the proactive ones.
- Not reading the ticket/building to spec. Most people aren’t very good at following directions, at least when they’re starting out. Particularly in UI development, you’ll likely review a few PRs where the code in question either looks like the mock up but is lacking quality in features or is feature perfect but looks rough [in other browsers][at different sizes]. This is usually an easy problem to solve, but it’s frustrating if you don’t expect it or are under a deadline.
- Not raising blockers/challenges. This is the cousin of not asking enough questions. Teach your developers about the ceremonies your team has and what functions they serve. As embattled an idea as Agile is, agile-style stand ups (I’m assuming you do them) are great and should be taken advantage of to both unblock and request more general help or info. Remember, if they aren’t asking questions of other people on the team then you will likely end up being the go-between, often too late in the process. This is an essential component of self-sufficiency.
- Bias towards action. Given a blank file and the fear of failure, the average junior dev is going to be very motivated to code something. This usually doesn’t go very well. Teach them to step back and think first before doing anything else. Reviewing the task requirements, discussing different approaches to solving the problem, and then pseudocoding a solution is a good way to start. As they gain experience, I recommend adding TDD into the mix as well.
What You Should Work On as a Mentor
Up to this point, this article has been focused on how you can bless the lowly junior devs on the team with your awe-inspiring and magnanimous brain-knowledge. That’s all fine and good, but it’s important to remember that you probably have some things you could work on as well.
- Patience. Software development is complex, abstract, and hard to learn. Those things seem obvious, but do you really remember to what degree that was the case when you were first starting out? If you don’t, you might struggle to find the patience for mentorship, as it can be a slow and grueling process. Take a deep breath (maybe two) and remember that in the medium-to-long term, the upfront investment in time pays itself back in the form of another ramped up and competent coworker.
- Empathy, particularly giving the benefit of the doubt. You’re going to review a lot of seemingly non-sensical code. You’re also going to have to repeat yourself often and correct issues that you thought you already headed-off and/or solved. As you do all of this, try to recognize that the person you’re mentoring is trying and that the things they do wrong are probably a lot more distressing to them than they are frustrating to you.
- Giving constructive feedback and moral support. It takes at least 3-6 months to ramp up a junior dev to where they can start to really contribute to a project. It’s a long time, and if you’ve ever been through it you’ll know that it’s very often humbling, demoralizing, and panic-inducing. It’s therefore important to provide praise or moral support where appropriate and to fine tune your feedback so that it’s kind, informative, and actionable. Point out where a PR gets something exactly right and where it might be able to be even better. Lend you junior devs some of your hard-won perspective when they’re feeling like they’re not learning fast enough, and help them understand what they can do to unblock their progress.
- Communicating simply and clearly. You’re going to get a lot of practice breaking down complex topics into meaningful and comprehensible bits, and, as mentioned above, it can be arduous. Luckily, it’s a skill that transfers broadly. At some point or another, you’re going to need to communicate technical topics to your boss, your boss’ boss, non-technical folks lateral to you, and other developers. If you want to be effective, you’re going to have to do it in a way that uses simple and clear language. So soak up the low-stakes communication practice you get from mentorship, if for no other reason than it benefits you too.
As I mentioned at the top, mentorship is no small topic and it’s something I’m still learning about and trying to improve at. That said, the above points have proven consistent across all the roles that I’ve been in, whether as a mentee or mentor. Hopefully they can be of some help to you.