A common, well-intentioned but limited approach to mentoring a junior developer is being highly available to answer questions — quick to respond, quick to unblock, quick to hand over the specific piece of information that gets someone past an immediate obstacle. This is genuinely valuable in the moment, but on its own it tends to transfer information rather than judgment, and judgment — knowing which question to ask in the first place, recognizing which of several plausible approaches actually fits a given situation — is generally the harder, more valuable thing a junior developer needs to develop over time. Additional community-leadership ideas appear in the Open Source Guides leadership resource.
Narrating reasoning, not just providing answers
A more effective mentoring habit, well documented in discussions of technical mentorship, is narrating the reasoning behind an answer rather than just providing the answer itself — not just “use this approach” but “here's why this approach fits better than the alternative you might have reached for, given these specific constraints.” This takes longer in the moment, which is exactly why it's easy to skip under time pressure, but it's the version that actually builds the judgment a junior developer will eventually need to exercise independently, on a similar but not identical problem, when a mentor isn't available to just supply the answer. Pair work depends partly on shared timing and attention; the full explanation explores the related idea of interpersonal synchrony.
This connects directly to the senior-engineer guide discussed elsewhere on this shelf: the judgment that distinguishes more senior engineering work — knowing when standard advice doesn't fit a specific situation — is exactly the kind of tacit, reasoning-based knowledge that's very difficult to transfer through answers alone, and much more effectively transferred through consistently narrated reasoning over many smaller interactions.
Letting someone struggle productively, on purpose
A genuinely difficult judgment call in mentoring is deciding when to let a junior developer struggle with a problem a bit longer before stepping in, versus intervening immediately to prevent frustration or lost time. Intervening too early denies the person the specific kind of learning that comes from genuinely wrestling with a problem, including the value of their own wrong turns and the reasoning process of eventually finding the right path; intervening too late risks real frustration, lost confidence, or enough wasted time that the exercise stops being productive and starts just being demoralizing. There's no universal correct amount of struggle to allow — it depends on the specific person, the specific problem's stakes, and how much time pressure genuinely exists — but treating this as a deliberate judgment call, rather than defaulting reflexively to either extreme, tends to produce better mentoring outcomes than either “always rescue immediately” or “always let them figure it out alone.”
- Narrate the reasoning behind an answer, not just the answer itself — it takes longer but transfers the judgment a junior developer will need on the next, not-quite-identical problem.
- Deliberately calibrate how long to let someone struggle before stepping in — neither immediate rescue nor total hands-off is correct by default; it depends on the person, the stakes, and the time available.
- Pair programming, discussed elsewhere on this shelf, is one of the more effective concrete mentoring formats specifically because it makes reasoning visible in real time, rather than only after the fact.
- Ask a junior developer to explain their own reasoning before offering yours — it surfaces their actual thought process, which is more useful information for calibrating what to teach next than jumping straight to a correction.
Why mentoring quality is hard to measure, and easy to underinvest in
Good mentoring rarely shows up clearly in short-term individual output metrics — time spent narrating reasoning or deliberately not intervening immediately can look, from a narrow, short-term productivity lens, like time not spent on direct output. Its real payoff shows up later, and diffusely, in a mentee's growing independence and judgment, which is genuinely harder to measure and credit than a completed ticket. This is part of why good mentoring, despite being widely acknowledged as valuable, tends to be underinvested in relative to its actual long-term impact on a team's overall capability.
Read alongside the pair-programming guide discussed elsewhere on this shelf, structured, reasoning-visible collaboration is one of the more reliable concrete mechanisms for this kind of transfer — considerably more so than availability for questions alone, however generously that availability is offered.