Thanks to all the coding bootcamps out there, many tech teams hired their first junior developers last year. Many more are now considering it, and debating how to go about it. Looking at the community chatter on this topic, it’s clear that onboarding junior devs into a team of mid- and senior-level folks is not a solved problem. Hell, my company is heading into its sixth cohort of apprentices, and the question of how to structure their time still provokes passionate debate internally.
The problem is that it all goes wrong so easily. The typical interaction patterns of a more experienced team are mystifying to someone new to all this, and it’s easy for a junior developer to feel unprepared, overwhelmed, and disconnected. Under those circumstances, they can hardly do good work, and your investment in their growth is unlikely to pay off.
I see a lot of teams combat this with pair programming. Pairing is widely regarded as a fantastic teaching method. Personally I like it for everyday development, but regardless of how you feel about that, we can all agree that pairing is clearly helpful when there’s a skill gap between the participants. Pairing gets junior devs up to speed more quickly than any other method I’ve seen. It also helps keep them connected and engaged.
But, if you haven’t done much pairing before, starting with a junior-senior match is like setting a game to ULTRA DIFFICULTY MODE for your first playthrough. If things go wrong, it’s hard to say why — inexperience with pairing? Junior dev too junior? Senior dev too…senior?
Even teams that pair every day find there are quirks in the process when there’s a big experience gap. Here are my top 5 recommendations for mid-level or senior developers pairing with junior developers.
1. Don’t type.
Seriously. Keep your hands off your keyboard. Instead, tell the junior person what to type. Or even better, ask them questions that help them figure out what to do next.
- “What kind of tests do we need for this?”
- “Hmm. Where do you think we’ll find the code that this controller is calling?”
- “What do you think about pulling this out into a method rather than duplicating it?”
The only way they’re going to learn is by doing it themselves, and that means they type and they move the mouse. Yes, you’ll go slowly. And yes, sometimes it will be maddening. But junior devs don’t learn anything by watching someone else program.
Not typing at all is an asymptotic ideal that I doubt anyone can reach. I never have. But I do try. I sit on my hands. I fiddle with a foam stress ball. I arrange those magnet sets from ThinkGeek into endless patterns. I’ve even resorted to unplugging my keyboard.
I don’t tune out. I’m still discussing and asking questions. I just give my hands something else to do, so I’m not tempted to TYPE THE THING IT WILL ONLY TAKE TWO SECONDS AND WE’VE BEEN DISCUSSING IT FOR TEN MINUTES. It helps me keep that monologue internal. =)
Believe me, your junior pair is painfully aware that they’re slow. They will want you to type. But if you want them to progress (and if you don’t, why are you doing this at all?), it’s critical that they type as much as possible.
2. Let them make mistakes.
On the flip side, if you always jump in and tell them exactly what to do, they don’t learn judgement — they just learn a set of rules to follow. You want to develop their judgement, even more than you want to develop their knowledge.
So sometimes, if they want to try something that you know will be a dead end, just say, “let’s try it, and see what happens.” You’ll reach that inevitable dead end, and then you have a great opportunity. Close the loop — help them understand how the previous decision got you there. They’ll start to develop that visceral sense of why they shouldn’t do it. You’ll end up with a far more effective developer than if they had just memorized rules.
Perhaps it doesn’t need saying, but these excursions don’t end with triumphal “I TOLD YOU SO”s. They end with discussions, rooted in the fact that the direction we went was totally reasonable, but went wrong because of X, Y, and/or Z.
3. Take breaks.
Pair programming with a junior developer is worthwhile, but surprisingly tiring. Even if you’re used to pairing, the experience gap means a lot of extra explaining. It’s ok to take breaks, both during the day, and between days.
Personally, I like doing one day on, one day off. I’ll spend a day pairing with a junior developer, and then the next day I either work on my own, or pair with someone I can go really fast with. OMG that feels good! Don’t burn yourself out.
4. Be prepared to say “I don’t know.”
A big advantage of having junior developers on your team is that they always see the man behind the curtain. They’ll ask questions about why things are done a certain way that you’ll not have thought about for years. Or maybe ever! And sometimes, articulating that why will be difficult.
But resist the urge to sweep those questions under the rug with the programming equivalent of “you’ll understand when you’re older.” Each one of these is a valuable opportunity to demonstrate that your team values learning, not just knowledge.
Say “I don’t know. That’s a great question, though. Let’s figure it out.” Then show your pair how you figure out something you don’t know. Seeing how a senior developer traverses the code base, or what they google when they don’t know something, is often way more useful to a junior developer than it seems to you.
Saying “I don’t know” thus serves two important purposes: it teaches research skills, and it demonstrates that even the senior folks don’t know everything.
5. Find what they can teach you.
The easiest way to drive junior developers away from your team is to always treat them like they know less. Sure, they know less about programming, and that will be true for a while. But you need to give them a chance to invert that relationship so that you feel more like social equals.
But how to do it? Well, when you’re waiting for tests to run, when you might otherwise look at your phone, instead ask them about their weekend. I guarantee you that every single person, no matter how junior, no matter how young, has something they’re the expert on.
Maybe they’re an amazing rock climber. Maybe they do ironman triathalons. Maybe they used to be a professional saxophone player! It sounds like useless chit-chat, but it’s actually super important for you to find this thing, whatever it is. Once you do, ask them thoughtful questions about it. Make it clear you don’t know much about it, but you want to learn.
You’re doing two very important things here:
- You’re modeling the behavior you want them to exhibit when they run into something they don’t know.
- You’re giving them a chance to feel more like your social equal.
How equal a junior developer feels within the team is the single best indicator of how long they’ll stay.
Wow. This is a lot of work.
Yep. Bringing on a junior developer requires determination and stamina from everyone on the team. However, they bring significant advantages as well, and on most teams right now, the calculus works out in favor of having them.
The most prosaic advantage of junior developers is that they’re available. Have you tried hiring a mid- or senior-level Ruby developer lately? You’d better have months to wait, not to mention investors with deep pockets. Alternatively, if your team can effectively make use of junior developers, you get a much larger and tremendously talented pool to draw from.
Another advantage is that bringing them on increases your code quality. You read that right. And I agree, it’s surprising. That’s the opposite of what I expected at first, since I was, after all, hiring less experienced people.
But when you bring in your first junior developer, it forces you to make explicit a lot of knowledge that was previously implicit between more experienced developers. The experienced folks may find it tedious at first, but this process always ends up surfacing inconsistencies and design flaws that otherwise you wouldn’t have caught until much later.
Finally, junior developers bring in a fresh perspective. The junior devs in our community come from a huge diversity of backgrounds, which gives you the opportunity to add someone to your team with a different perspective from everyone else. These new perspectives will increase chaos in the short term, but in the longer term will push you towards better solutions.
Just remember: don’t type.
Tandem is custom software development company in Chicago and San Francisco with practice areas in digital strategy, UI/UX, and custom web application development.
