Illustration by

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.

Article Continues Below

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.

About the Author

Alice Mottola

Alice Mottola first became interested in computer science while attending Barnard College in 2010. After graduating with a degree in biology, she spent two years acting and planning extravagant children’s birthday parties before finally returning to the world of machines. She has been a Rails developer at Constant Contact since October 2013.

13 Reader Comments

  1. This is great! One of the developers on our team is mentoring someone from a different part of the company. The mentee visits our office twice a week to shadow the developer as he works on different projects. Just hearing him explain his workflow and processes to a relative newbie is pretty useful to me, and I think to the other developers as well. It brings a nice element of openness and learning to our workdays.

  2. Thank you for sharing! It sounds like the arrangement you describe would be a great way for people to dip their toes into mentorship and gain some of its team-wide benefits without making a long-term commitment.

  3. Thank you for this article. The acquisition of good mentoring skills is often overlooked, yet the value of good mentoring within a team cannot be over-emphasized. Personally, in my 22 years in IT, I’ve stumbled upon many of the points you made. But not all. I have been educated. Thank you again.

  4. Great article. I feel privileged to go through this process at some point of time, when I was mentored in a really good, structured way. You just described this above. I went through all these phases, thanks to mentor I had, at my first web development role. That’s why I understand how important it is, to have someone with great mentoring skills, to talk with. This article summarises this importance, and provide a guidance, as now I’m looking forward to become a mentor myself 😉

  5. Thanks for the article. I believe that mentoring is a very powerful tool, but also find it to be extremely hard sometimes. Especially when a mentee does not absorb the knowledge you give him and falls to his old (bad) habits of making code and working in a team. It is even harder if this person is a senior developer that should know how to behave, but somehow he does not, and you need to mentor him because no one else is going to do that. Changing his fixed thinking is a sisyphean task.

  6. If you’re trying to change the behavior of someone who’s experienced but inflexible, then mentorship might not be the best model. Unfortunately, you can’t successfully mentor someone who doesn’t want to be mentored. Instead, why don’t you consider some well-intentioned social engineering?

  7. Great article Alice! Becoming a mentor helps you to learn more about something. I have been through the phases you mentioned above and I can say that it’s an amazing feeling for one to become a mentor. When it comes to the relation between a mentor and a mentee, it should be very strong, so that there is a mutual understanding between both of them.

  8. Great article, thanks for sharing. Sometimes you don’t have the luxury to choose people you mentor, and there comes the challenge. It is not always up to you to become a successful mentor specially if your mentee which u can’t choose is somehow as u mentioned arrogant. For me i try to find a common ground where i can agree with my mentee on for example agility and that can be the starting point to build or fix the relationship

  9. The problems with the young interns we have is they don’t want to specialize in a coding language and are fine to be just ok at everything. Very difficult to mentor.

  10. Thanks for the article. I believe that mentoring is a very powerful tool, but also find it to be extremely hard sometimes.Harga Kompor Gas Terbaru Terlengkap
    – Especially when a mentee does not absorb the knowledge you give him and falls to his old (bad) habits of making code and working in a team.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA