The line between helpful guidance and patronizing lectures is thin. Here's how I learned to walk it.

#Mentoring #Career #Leadership

The Default That Doesn't Work

When I first started mentoring junior developers, my default approach was to explain things thoroughly — to break down every concept, provide context, and make sure they understood the "why" behind every decision. That approach came from a good place: I remembered being a junior and feeling lost, and I wanted to spare them that feeling. What I didn't realize was that thorough explanations, when they're unsolicited, feel patronizing. A junior developer who asks "how do I fix this bug" doesn't want a lecture on the architecture of the debugging tools — they want a hint that points them toward the fix. Over-explaining communicates that you think they can't figure it out themselves, which is the opposite of the message you intend to send.

The shift that helped was learning to calibrate the level of detail to the question being asked. "How do I fix this bug" gets a specific hint, not a lecture. "Why does this pattern work this way" gets the architectural context. "Can you review my approach" gets a discussion of trade-offs. Matching the response to the question respects the junior's agency and communicates that you're responding to their actual need rather than to your assumption about what they need. That calibration takes practice, because the default for someone who knows a lot is to share everything they know, and reining that in requires conscious effort.

Asking Instead of Telling

The single most effective mentoring technique I've learned is to ask questions instead of giving answers. When a junior asks "how should I structure this component," the tempting response is to tell them how I'd structure it. The better response is to ask "what are the constraints you're working with?" or "what approaches have you considered?" Those questions force the junior to articulate their own thinking, which is where the actual learning happens — not in hearing my answer, but in developing their own. My answer gives them a fish; their answer teaches them to fish. The ratio of questions to answers in a mentoring conversation is a good proxy for how much learning is happening, and I aim for a high ratio.

The other technique that works well is pair programming on hard problems. Pairing puts the senior and junior in the same problem-solving context, which means the junior sees the senior's thought process in real time — the dead ends, the debugging strategies, the moments of confusion. That visibility is valuable because it demystifies the senior's competence; the junior sees that the senior doesn't know everything instantly, and that the process of figuring things out is the same for everyone, just faster with more experience. Pairing also gives the senior visibility into the junior's thought process, which makes it possible to offer targeted guidance rather than generic advice.

The Patience Problem

The hardest part of mentoring is patience. When a junior is struggling with something I could do in five minutes, the temptation to just do it for them is strong, because it's faster and I know it'll be done right. But doing it for them teaches them nothing, and it creates a dependency where they keep coming to me for the same kind of problem. The investment of letting them struggle — being available to help, but not taking over — pays off when they solve the next similar problem on their own. That payoff is delayed, sometimes by weeks, which makes it hard to feel in the moment, but it's the only way to build capability rather than just completing tasks.

Mentoring is also, counterintuitively, one of the best ways to learn yourself. Explaining a concept to a junior forces you to articulate things you've internalized to the point of not noticing them, and the act of articulation often reveals gaps in your own understanding. Questions from juniors — especially the "why" questions that challenge assumptions — surface the implicit knowledge you've accumulated and force you to examine whether it's actually correct. Some of the deepest learning I've done has been in response to a junior's question that I initially thought I knew the answer to, only to discover that my answer was based on convention rather than understanding. Mentoring isn't just giving knowledge away; it's a mechanism for deepening your own.