How to Mentor New Developers

As a female developer, mentorship has always been important to me because it seemed the only way to reach gender-parity in technical fields. I also remember, early on in my career, how frustrating it was when I went to interview in places that told me things like "mentoring new developers isn't one of our strong suits as a company."

I can understand why a startup in the first 1-2 years of its lifecycle may not have space to take on junior developers, but for more established companies, it doesn't just strike me as sightly arrogant to dismiss the importance of mentorship, but actually somewhat dangerous. Something I noticed about companies that "only hired senior developers" is that, they didn't actually seem to have more experienced developers than companies that were willing to hire mid-level or junior developers, but they did have a lot more people lying about their qualifications.

Companies that penalize inexperience create incentive for people to hide what they don't know, which is terrible both in terms of personal improvement, and in terms of long term code quality. I have seen "senior" developers do absolutely insane things, like push code live without even running it once, or design entire back ends for full stack sites before starting on the front end because they were afraid to admit to the team that they didn't know how to do something. Instead of asking for help, or even simple clarification from other devs, they tried to hide their ignorance in an effort to protect their job.

This is exactly backwards to how you want it to be. Ideally, you want your devs to feel comfortable coming to you with any and all mistakes, as quickly as they can. I remember, once, one of my devs came to me panicked because she thought she had deleted the client's (non-backed up) database. My first words to her were, it's ok, we can figure this out. (It turned out to be an easy fix because she hadn't deleted the database, but from thereon out, my first step before starting work on any live site is to make sure all the backups are functioning.)

But when it comes to devs, especially junior devs, that has to be your motto; it's ok, we can figure this out. Junior developers are under immense stress all the time, because not only are they learning on the job, but they also feel like they're going to be penalized or potentially fired for any mistake they make. This is actually a terrible environment for learning, so it's important to offset it as much as possible.

One of the first things you want to do on a technical project with junior developers is put some guard-rails in place to limit any kind of damage they could do to the project (for this, I'm thinking of a "junior developer" as someone within 1-2 years of taking a bootcamp, of fresh from a college program.) Here are the main safeguards I personally like to use:

1. Make sure any backups (e.g. database) are functioning, and prioritize this above everything else. If backups go down, fix this before continuing development. If something can't be backed up (e.g. if it's very large and would be price prohibitive) don't let junior people work there.
2. Don't allow force commits (even for senior devs) without group discussion. It's important to not let the senior devs do it, even if they're responsible about it, because the junior devs might copy them.
3. Ideally, have continuous integration tests working and running for the entire project; if not, at least make sure the junior devs write test for their own code.
4. Ideally, have code reviews for everyone; if not, make sure you at least have code reviews implemented for junior developers.
5. Ideally, get a good PM or tester to checkoff submissions on staging, and get someone to go through the important site flows at least once a week.

So, once you've set the rules of the playground what's next?

The #1 thing I like to impart to any junior developer is how to do testing. Now, back in the day, I used to believe that all programers should aspire toward 100% test coverage all the time. What changed my view on that, is that, I actually worked at a lot of startups that were very successful but had minimal testing; now, I think that, the degree of testing a site needs depends on the repercussions of failure (e.g. a medical site needs more testing than a humor site) and the social culture of the development team.

However, junior developers still need to test (close to) 100% of their code! Sorry, life can be hard sometimes. Part of the reason for this, actually, is that a lot of junior developers don't really understand how to do testing; they don't understand the conditions that are likely to make their code brittle. Testing can help impart this understanding more generally, so in writing tests, they learn how to write more stable code overall.

This can be a bit of a complex topic, but at the very least I want my junior devs writing unit tests with the following cases as a starting point:

1. A test case for expected pass
2. A test case for expected failure
3. A test case for the "zero" case
4. A test case for the "one" case
5. A test case for "average use" case
6. A test case for "large use" case

Not that they necessarily have to write all of them all the time, but that if they decide not to write a particular type of test, they need to understand why it's not relevant in that case. Additionally, I ask them to consider if there are special use cases that need to be considered for their particular piece of code (e.g., if a function behaved differently for even or odd input, you'd need to break many of the above test cases into "even" and "odd" versions of it.) In general, bluntly, I find junior people to be not very good at writing tests because they haven't yet learned to reason about their own code. Yes, the writing of tests will likely help catch errors, but more importantly, it's teaching them how to reason about their own programming.

Another thing that I try to get all junior developers to do, is both give and receive code reviews. I tend to find, that most junior developers are very open about receiving code reviews, but tend to dislike giving them because they see themselves as not senior enough. In an ideal world, you'll have two junior developers who can review each other's code (as well as having a senior developer check off on it as well) but sometimes that's not possible. I'll often ask junior developers to review my code if there isn't another junior developer around, but I will admit, that they often hate this because I'm frequently working in areas of the codebase that are unfamiliar to them. If they're not up to giving me a full code review, I at least ask the to try to reason about the code that I've written, and ask me questions about what they think the functionality is. Again, I believe this is something that helps build their ability to reason about code in the abstract, but I will admit it's usually not people's favorite part of the job.

I guess finally – and perhaps we should have started with this question – we must consider when and how does a junior developer become a mid-level developer? That is, of course, ultimately the goal of mentorship but just what does a mid level developer look like?

To me, a mid-level developer is someone you can set loose in a codebase, and a) they won't (usually) break anything, and b) they can basically figure out how about 80% of it works without too much help. If you assign them a task, they can usually get on with it by learning from the existing examples in the code, or by googling similar problems. A senior developer can do all this, but they would also be capable of other high value tasks – these additional tasks could be management, they could be highly specialized programming subsets (e.g. machine learning or computer vision), they could be a sense of good architecture that helps them lay out new codebases or refactor old ones. It's hard to break down what makes a developer senior, since many things can make a developer senior depending on their speciality; it's a bit easier to evaluate the junior and mid-level devs.

So, fundamentally, transitioning a junior developer to a mid-level developer means transitioning them to have increased self reliance when programming in a project. While I disagree with many companies reluctance to take on junior developers, I do understand it. A mid level engineer is probably about 10 times as productive as a junior engineer, and about twice as expensive. That's a hard sell in a capitalist world; additionally, given that it's possible for a junior engineer to just come and learn some skills and immediately bounce. That said, most won't do that, but in order to hire junior engineers effectively, a company has to be in a position to take a one year gamble on someone.

At their best, however (and, I hate to admit this so directly) junior developers are often willing to do tasks that mid level and senior developers find very boring so they greatly add to the culture of a company. When I was first learning HTML/CSS, I found it fun because it had a large visual component to it, but after about 5 years, it became tedious and I always tried to get it done as quickly as possible. One day, under a lot of time pressure, I asked one of my junior devs to fill out the rest of my HTML/CSS for me – I gave her an example of how to do it on one page, then told her to go fix it on the rest of the pages.

Eventually, I came back to apologize to her for giving her such a boring task, and she said "No, it was great! I felt like I really learned a lot from doing all that." And I remembered, doing HTML/CSS stuff isn't boring the first time you do it. While I don't agree with giving junior people boring, mind numbing work often times they genuinely won't see certain things as boring. It's a lot less boring to learn something than it is to do something for the 100th time, which is easy to forget.

So, what does a highly effective junior engineer look like in a team?

1. They are transitioning to becoming more and more self reliant, by learning how to reason about code and solve problems with less assistance
2. While they are often slower than more senior members of the team, the primary way they increase team efficiency and morale is by pulling the lower level tasks away from more senior people, which is often why senior people find it worth their time to mentor them
3. The scope of the problems they are able to solve is generally increasing, and it should take 1-2 years for them to be functioning as a more "mid-level" engineer in context (if they switch jobs or programming speciality, it may take longer.) This can make them economic choices if you have good programmer retention rate.  

Conversely, another way to (sadly) judge this is to look for signs that a junior engineer isn't working out.

1. They keep asking the same questions over and over again. I give people a little bit of a pass if there's been a gap between both times they've asked, and I'll suggest note-taking if it hasn't occurred to them before, but I have also had junior engineers where I've literally had to explain the same thing to them daily. Often, this is a sign that they're not able to fully concentrate on their work for some reason; it can be something that will pass (like personal life stuff) but it can also indicate a deeper lack of interest from someone. Fundamentally, if someone isn't curious about solving problems, you're at a bit of a dead end until that curiosity arrives.
2. They're never able to complete tasks by themselves. As a female engineer, I will say, I am very sensitive to the gender dynamics of this one; sometimes I get female boot camp graduates where male students were trying to be encouraging by doing the student's work for her. The number 1 thing I do with all new engineers (but, I'm especially mindful of this with women) is I make them do all the typing themselves and this starts with setting up their computer. Often, people find this stressful – so, I take the time pressure off, and tell them I don't care how long it takes them, but they will be the ones to do it. In my experience, eventually everyone learns how to do their own work themselves (and, gains confidence from having done it independently.) But, I have met junior/mid level engineers who are kind of stuck because they never developed the confidence to solve hard problems alone. What happens is quite sad; the other engineers will complain about this person behind their back and refuse to respect them fully. I don't want any of my junior devs ending up in that situation, especially because it's avoidable if you're willing to be a bit hard on them in the beginning.
3. There are signs they're in the wrong specialization. This isn't a disaster, but it is something you need to address. Because a lot of my experience is working at startups where people wear many hats, what will sometimes happen with a junior developer is they'll often be attracted to the softer side of work – wireframes, writing stories for other devs, etc. There's nothing necessarily wrong with that, but they're not on track to be a programmer if they keep doing this. So, the decision that needs to be made, is we need to figure out if it's appropriate to transition someone into being a junior PM, or if they're just lacking a little confidence and they need to double down on their technical work. In general, when people are junior, I try to encourage people to develop their harder skills (unless they really don't like it) because it's usually easier to transition from technical to non-techncial than the other way around. So, I push people to stay as technical as possible as long as possible, but sometimes you do need to accept that someone is really more of a PM than a dev, and that's ok.

Overall though, I'd say the biggest barrier to entry for new developers is that computers are merciless. You can have perfectly written code that chokes over a semicolon; being 99% right is as good as 0% right, and this is emotionally hard for people to come to terms with. It can also be hard to watch, and one of the biggest mistakes I see people make with junior developers is they want to save them from the pain of failure.

But, you can't save them from this. Failure is part of the training.

Sometimes, if I have a junior dev feeling very discouraged, I tell them about how much I used to cry when I was learning how to code.

You used to cry over code? They'll ask.

Frequently, I'll reply. It's often shocking for people to learn that, but I think we do people a disservice when we try to sugarcoat something. Learning how to code is hard, people deal with hard things in different ways. Me, personally, I cry.

It's ok to cry sometimes.

Do you still cry over code? you may be wondering.

Not in over ten years. The thing is, eventually, you get used to not knowing the answers off the bat. You develop a kind of faith in your own ability to figure something out. You know someone's going to dump a behemoth of a technical question in your lap and two weeks later you're going to have a solution for them. You develop this faith out of experience; you remember all the other times someone gave you a problem you didn't believe you could solve, and magically you solved it!

When you're talking to junior developers, there's usually a secret conversation going on.

What they're saying to you is, "I don't believe I can do this."

What you're saying to them is, "you CAN do this, I know you can." But as the senior dev, you can't solve their problem for them because then they will still believe they can't do it. You have to guide them to solving the problem themselves. But, once they jump beyond this – once they start having faith in their own ability to solve problems because they've solved enough of them – then they're ready for the next step in their career.