Initiation to Code

When you imagine a programming mentor, certain archetypes might flash into your mind. Maybe you see the wise monk who’s meditated on design patterns for decades. Perhaps it’s the sophisticated keynote speaker with a staggering list of open source contributions. Or it might be that mad scientist polyglot obsessed with a dozen languages you’ve never heard of.

But if these characters aren’t on your team when the new hire straight out of school joins up, who’s going to take the reins of training?

You, of course.

With the rise of coding boot camps and increased enrollment in computer science courses at universities, the pool of junior developers is larger than ever. But when it comes to nurturing all this talent, many teams don’t know where to start. Some developers think they don’t yet know enough to be a good mentor, while others think they’re just too busy for it.

Whatever your initial reservations may be, you can mentor, and you can do it well. All you need are the right guidelines and a little bit of structure.

Starting the mentor–mentee relationship#section2

When you’re seeking a mentee, look for “someone who has something to teach you, but doesn’t know it yet,” as a friend of mine who mentors at RailsBridge recently suggested.

I take this to mean two things. The first is to stay open to a range of personality types. Look for a mentee who’s not similar to you. It can be tempting to compare juniors to yourself-three-years-ago and jump to conclusions from there. But mentorship is a two-way street—it’s not about lecturing. In fact, it’s not even about passing your knowledge down to another person. It’s about making a mutual agreement to get better at what you both do. You’ll learn more from each other if you have different ways of thinking.

The second is to choose someone you want to learn from. If your mentee isn’t the type of person you’d be happy to march into code battle with, you won’t get anywhere. The primary quality to avoid is arrogance; an arrogant person will have a slower rate of growth than someone who takes feedback gracefully.

Because team dynamics are constantly in flux, you might not often establish formal mentor–mentee relationships with people on your team. That doesn’t mean you won’t find opportunities to mentor. Look for little moments to step in and help; you’ll be viewed as a leader, and more mentoring opportunities will begin to materialize.

Agility is the key#section3

The key to being a good mentor is a concept you’re already familiar with, since it’s also the key to developing good software and learning new information effectively. That key is agility.

Of course, “agile” has become a pretty loaded term that tends to confuse more than it clarifies. In a 2014 blog post, Dave Thomas, one of the original signatories of the Agile Manifesto, acknowledged this confusion. Then he reminded us how to do anything in an agile fashion:

• Find out where you are
• Take a small step toward your goal
• Adjust your understanding based on your goal
• Repeat

Or as the Scrum Guide puts it: “inspect and adapt.” Inspecting and adapting are foundational to being a good mentor. If you don’t take the time to check up on your mentees and listen to their concerns, travails, and triumphs, then you will have no metric for achievement.

Employing agility as a mentor requires sensitivity, creativity, and solid communication skills. It also requires the foresight to see what your mentee should be aiming for, and the hindsight to see what your mentee has already accomplished.

To establish a framework for gauging your mentee’s progress, consider the three phases every new team member goes through in some form. The first phase is total unfamiliarity and constant discovery; the second is a transitional period with a clear trajectory of progress; and the third is self-driven competence. In all three phases, remember that agility remains your most vital tool.

Phase 1: a little respect#section4

On the very first day, have a conversation with your mentee in which your goal is to discover exactly what their level and type of experience is right now. This conversation serves a dual purpose. First, it establishes a two-way discourse, a communicative relationship that will underpin your agile approach to mentorship. Second, it gives you a basis to decide what to assign to your mentee first. Starting off with a direct conversation can prevent an incredible amount of confusion and wasted time.

Pair programming at this stage is pretty much mandatory. It’s far and away the best method for getting a new developer up to speed, especially if you have a large or confusing code base. A recent article by Sarah Mei makes some excellent points about how to pair effectively, but the most salient one is this: don’t touch the keyboard (much). Ask questions, and answer questions with more questions. The closer you are to your mentee’s level of experience, the harder it is to take the backseat approach, since you’re often just figuring things out yourself. But whenever you feel the urge to barge ahead and solve the problem, resist! Your mentee will learn much more effectively in the Socratic style.

Keep in mind, though, that you aren’t only a technical guide. Early on, gaining technical experience probably won’t be the first thing on a junior developer’s mind—much to their surprise. They’ll be confronted with social puzzles and process nuances that everyone else takes for granted. Clear away confusion over all the things surrounding the work so your mentee has no obstacles to digging down into the work itself.

As eager as you might be to keep things moving, make sure to be honest about your own limitations, too. Consider phrases like: “I don’t understand this, either.” “I need to take a break.” “I can’t help right now, but try asking Oleg.” All of these can be music to a beginner’s ears. The more truthful you are about when and how you and others can help, the more realistic your mentee’s outlook will be. And a realistic outlook leads to good decisions.

Phase 2: challenge accepted#section5

With a solid communicative relationship established, your mentee will quickly move past the green stage. You’ll know that they’re in Phase 2 when they can easily figure out what needs to be done on a ticket, even if they don’t know quite how to do it. This means they’re starting to get comfortable, and it’s also when things get really fun. It’s time to add challenge to the mix.

Whatever you do, don’t simply assign your mentee whatever happens to come up. Instead, inspect, adapt, and select assignments that build on what your mentee has done before. If possible, try to tell a story with your assignments. Something in the next ticket could elaborate on or reinforce a concept from the previous ticket. Or you could tell the story of a single request, from UI to database and back again.

If you must assign your mentee something that looks relatively simple, use it as an opportunity to train them in looking at code with a pessimistic eye. What would a null input do? Does this open any vectors for attack? Could you have refactored another component to make this change easier? Do your tests cover all the new code? Even if your mentee decides that the code is airtight (which it never is), they’ll exercise their programming muscles trying to answer your questions.

While you challenge your mentee at every turn, don’t forget to take a lot of opportunities to encourage. A task that seems routine to you might feel like a triumph for your mentee, so when they finish something, congratulate them. And never underestimate the power of a simple “Good job.”

Phase 3: the initiation game#section6

Your ultimate goal is to transform your mentee into a productive, contributing team member—an equal. With enough time and practice, they’ll eventually get there. But why wait? There’s a better, faster way. When your mentee is ready, you can help the transition along with a tool as old as humankind: initiation.

No matter who you are or where you’re from, you’re familiar with the narrative of initiation. Joseph Campbell identified it as one of the major elements of the hero’s journey, the underlying pattern shared by epic tales all across the world. From ancient mythology to pop culture mainstays like Star Wars and Fight Club, initiation stories have taken countless forms. The framework, however, is always the same: a harrowing ordeal that, if survived, yields the initiate to a new and higher level of awareness.

Initiation isn’t just for epic heroes. It’s a powerful tool for transformation in any context. When you feel your mentee is ready to take a big step, assign a task that seems a little too complex, a little too far outside the scope of what has been done before, and just difficult enough to accelerate the transition into an equal, independent team member.

An effective initiation for a software developer should have three qualities:

1. It would not be trivial for someone with a few more years of experience.
2. It demands communication with senior-level people. Ideally, the mentee will gain some insight into the factors that go into a high-level technical decision. Overhauling a UI component, modifying your deployment architecture, or hand-rolling a new caching strategy are all good candidates for this type of experience.
3. It has a demonstrable, preferably quantifiable, value. It might be a new front-end feature, or it might be a graph that shows a decrease in page load time, but ideally, your mentee will be able to point to a visual representation of the change and say, “I’m responsible for that.”

Often, initiations are accidental, a natural outgrowth of increasing experience and responsibility. But if you do set up a conscious initiation for your mentee, you don’t need to tell them that you’re doing it. In fact, you probably shouldn’t. Show your mentee you believe in them by treating them like a regular engineer.

If the initiation is successful, your mentee will become an equal—though an equal who still has a lot to learn. They’ll be able to drive their own progress without much hand-holding, and pairing sessions will feel more collaborative than instructive. After this transition, you can take a big step back, but continue to guide and challenge when necessary. After all, as Robert Anton Wilson said, a true initiation never ends.

Mentoring benefits the whole team#section7

When I first joined my team, I was the only junior developer. Now, our membership has grown and shifted, and almost half of us are juniors.

I’ve seen firsthand how much this shift has changed our dynamic for the better. Experienced engineers pose questions to the juniors, motivating them to refine their knowledge—and the juniors pose questions right back. Instead of a couple good communicators bearing the brunt of training, everyone is actively skill-sharing all the time. Where once individuals were siloed, there’s now a spirit of collaboration and fun. Willingness to learn and adapt has become a core value for the entire team.

It has also observably driven up our code quality. Fresh eyes are great at identifying anti-patterns, style issues, and confusing bits of code. With a healthy mix of juniors, we’ve become better at balancing technical debt repayment and pushing out new features, and the new code we merge is easier to maintain. Without mentorship, these improvements would never have come about.

Software engineers are fortunate to work in an industry where the tools and processes for collaboration are both well-defined and popular. But to paraphrase the Agile Manifesto, it’s the people and interactions that really make or break a product. Mentorship is a powerful interaction that, done right, can elevate your team’s quality of both life and code, and lay the groundwork for a more successful organization.