The pull request was small enough to review before lunch, but I still remember pausing at one comment box with my coffee cooling beside the keyboard. A junior developer had solved the problem in a way that worked, but the shape of the code told me they were guessing more than deciding. I could have left three direct instructions and moved on. Instead, I asked a slower question: what trade-off were you trying to protect here?
That moment is closer to real mentoring than most formal mentoring language. It does not always look like a career plan, a training calendar, or a neat checklist of skills. Often it is a senior person noticing the small hesitation inside ordinary work and choosing to make the thinking visible. The code matters, but the person learning how to think through the code matters too.
When I first started mentoring junior developers, I was too quick to be useful. Someone asked a question, and I answered. Someone hit an error, and I recognized it. Someone was unsure about a design, and I described the path I would take. It felt generous at the time, but it quietly taught the wrong habit. The junior learned that the fastest route through confusion was to borrow my certainty, and I learned to feel helpful because people kept coming back.
Good mentoring needs more patience than that. A junior developer is not only missing syntax, patterns, or framework knowledge. They are missing context. They may not know why this feature matters to the user, which parts of the codebase are fragile, which constraints are business rules and which are historical accidents, or what kind of risk deserves escalation. If we give only the answer, we may close the ticket while leaving the map blank.
Context is the first gift. Before a task starts, I try to explain the shape around it: what the feature is for, who will notice if it fails, which previous decision affects it, where the dangerous edge might be, and what a good enough first version looks like. This does not need to become a lecture. Five calm minutes can save many hours of anxious guessing. It tells the junior they are not walking into a dark room alone.
The second gift is calibrated support. Too little support turns mentoring into a test of survival. Too much support turns it into step-by-step dependency. The useful middle is usually a task that is slightly wider than their current comfort, with a visible safety net nearby. I like to agree on checkpoints before the work begins: show me your plan before implementation, ask if the data model changes, call me if the error points outside this module, and otherwise try to move through the first version yourself.
Confidence grows best in that middle space. It does not come from praise alone, and it does not come from being protected from every mistake. It comes from collecting evidence: I investigated the bug, I made a small design choice, I handled the review, I fixed what I missed, and the system still held. Every small completed loop becomes a little more trust they can carry into the next task.
Code review is one of the strongest places to build or damage that trust. A review comment can teach someone how to reason, or it can teach them to hide. When reviewing junior work, I try to separate correctness from embarrassment. If something is wrong, say it clearly. But also explain why it matters, what risk it creates, and how to think about similar cases next time. One specific comment that improves judgment is worth more than ten small corrections that only prove the reviewer is senior.
There is also a limit to how much one review should teach. When a pull request has many issues, it is tempting to turn the thread into a full course on architecture, testing, naming, error handling, and product thinking. Usually that overwhelms the person. I would rather choose the two lessons that matter most, help them finish the current work safely, and carry the rest into pairing, a follow-up note, or the next task. Mentoring is accumulation, not a single dramatic review.
Recoverable mistakes are part of that accumulation. A junior developer who never gets to make a safe mistake also never learns the weight of a decision. The mentor's job is to keep the blast radius reasonable, not to remove all risk. Let them choose an implementation path, miss an edge case in a low-risk area, or debug a test failure longer than you would. Then sit with them afterward and ask what signal they would look for earlier next time. The learning is not only in avoiding the mistake. It is in recovering without shame.
Psychological safety becomes very practical here. It is not a poster on the wall. It is whether a junior says they are confused before the confusion becomes a week of quiet drift. It is whether they can say they broke something without preparing a defense. It is whether a question in code review feels like an invitation to think, not a trap. The senior person's first response in those moments teaches the team what kind of honesty is safe.
Independence should arrive gradually. At first, the mentor may help shape the plan closely. Later, the junior brings options instead of only problems. Later still, they make the ordinary decisions alone and escalate only when risk changes. I like this movement because it respects both sides: the junior earns room through visible judgment, and the mentor learns to stop holding work that no longer needs to be held.
Mentoring also reflects the health of the system back to us. If several juniors ask the same question, maybe the onboarding is unclear. If every task requires private context from one senior engineer, maybe the codebase hides too much history. If people are afraid to ask early, maybe the team has rewarded certainty more than learning. A good mentor does not only improve the junior. They improve the conditions around the junior.
The best mentoring progress is easy to miss while it is happening. One day the same developer who once waited for confirmation starts explaining a trade-off to someone else. They leave a calmer pull request description. They catch a risk before review. They ask for context without apologizing for needing it. None of that appears overnight. It is the result of many small moments where support was close enough, but not so close that it took away ownership.
Maybe effective mentoring is simply this: help someone feel safe enough to be honest, supported enough to try, and trusted enough to become less dependent on you. If you have mentored a junior developer, or been mentored through that early uncertain season, I would be glad to hear which small moment made the biggest difference for you.