Mentoring

The problem: two wrong ways

Omid is a junior programmer. Today he joined the online shop team. His first task is building a “wishlist”. Reza, the team’s Senior, is his mentor.

Reza can make two common mistakes:

1. Leaving him alone. “Ask me any question you have.” Then he gets busy with his own work. Omid feels shy about asking all the time. He is stuck for three days on an error whose answer took five minutes.
2. Doing it for him. Each time Omid gets stuck, Reza takes the keyboard and solves the problem. The work moves fast. But three months later, Omid still cannot work without Reza.

In both cases, the team does not get an independent programmer. In the second case, Reza also gets tired, because all questions come to him.

What does a mentor do?

The mentor’s goal is one sentence: one day Omid must be able to work without me. Everything the mentor does must help this goal.

A good mentor moves between teacher and coach. For a completely new tool, they are a teacher. For a problem Omid can solve alone, they are a coach.

The first week: prepare the ground

Most people judge in the first week how helpful the team is. A simple checklist:

1. On day one, the project runs on his machine. If this takes a full day, the problem is the team’s documentation, not Omid. Wherever he gets stuck, ask him to fix the document.
2. In the first week, one small change goes to Production. For example, fixing a text or a small bug. Omid sees the whole path once: branch, Pull Request, review, CI and deploy.
3. Give a big-picture map. What are the main services of the shop? Where is the order data? One picture on a whiteboard is better than a hundred pages of documents.
4. Tell him who knows what. “Ask Mina about payment questions.” This way all questions do not come to you.
5. Set a fixed meeting. For example, ten minutes every day in the first week. Questions pile up, and Omid does not feel he is bothering you.

The steps of help

Help should not always be the same size. As Omid improves, help gets smaller.

1. I do it, you watch. Reza builds the first endpoint and thinks out loud. “I write the test first, because …”
2. We do it together. Pair Programming. Omid has the keyboard. Reza watches the path and asks questions. These two roles are called the Driver and the Navigator.
3. You do it, I watch. Omid builds the next endpoint alone. Reza only comments in the code review.
4. You alone. Omid picks up the task and does it alone. He can even help the next new person.

A question instead of an answer

Omid says: “The test fails.” The easiest thing is to tell him the answer. But this has a hidden cost.

A few questions that almost always help:

1. “What exactly does the error message say?” Very often the answer is in the message itself, but nobody has read it fully.
2. “What have you tried so far?” This shows how Omid thinks.
3. “What did you expect to happen?” The difference between what you expect and what is real shows where the problem is.
4. “What is the smallest code that shows this problem?” This is an important debugging skill.
5. “If I were not here, where would you look?” This question trains independence.

Also set a rule for Omid: “First try on your own. If you make no progress after, for example, thirty minutes, you must ask.” This rule fixes both mistakes: being stuck for a long time, and asking without thinking.

The right task: a bit harder

People learn when the task is a bit harder than their current level. A very easy task teaches nothing. A very hard task scares them and kills motivation.

In the shop, Omid’s path can be this:

1. Month one. The wishlist: a complete but simple feature, with a database and an API.
2. Month two. Sending an email when an item on the wishlist is back in stock. His first work with events and a message queue, with Reza’s help.
3. Month three. Making the wishlist page faster. Omid finds the problem himself and proposes the solution in a short document.

Feedback: specific, early, about the work

General feedback does not help. “Good job” or “You must be more careful” does not say exactly what to keep doing or what to change. A simple format for specific feedback is SBI: Situation, Behavior and Impact.

1. Situation. Where and when? “In yesterday’s review.”
2. Behavior. What exactly was done? What you saw, not your own reading of it. “There was no test for the empty list case”, not “carelessness”.
3. Impact. What was the result of this behavior? “The page broke for new users.”

After these three steps, open the conversation: “Next time, how can we find this earlier?” Maybe the answer is a change in the team checklist, not only in Omid’s work.

The same format works for praise too: “In yesterday’s meeting (situation), you explained your design with a simple picture (behavior). The whole team agreed in ten minutes (impact).” Specific praise says exactly what to keep doing.

One-on-one meetings and a safe space

A short regular meeting, for example half an hour every two weeks, is a place where Omid can say things he does not say in the team meeting. This meeting belongs to Omid, it is not a status report.

A few good questions for this meeting:

1. “What did you learn in these two weeks?”
2. “Where did you get stuck, or feel your time was wasted?”
3. “What would you like to be able to do six months from now?”
4. “What can I do better?”

All of this works only when Omid feels safe. That means he knows that saying “I don’t know” or “I made a mistake” does not hurt him. The mentor builds this space with their own behavior:

1. They say “I don’t know” themselves. “I don’t know this. Let’s find it together.”
2. They tell about their own mistakes. “Once I locked the whole orders table on Production. That is how I learned.”
3. After an error, they do not look for someone to blame. The question is “What allowed this to happen?”, not “Who did this?”.

Common mistakes