Someone invested in me
I am where I am because people took the time to review my work, explain what I could not yet see, and show me a higher standard. They could often have fixed the problem themselves in less time. Instead, they chose to teach. That investment changed more than the code I wrote next. It changed how I thought about the work, what I expected of myself, and what I believed I could become.
Review the thinking, not only the output
A shallow review catches syntax. A useful review examines naming, boundaries, failure modes, tests, tradeoffs, and whether the design will still make sense to someone else. The aim is not to leave the most comments or impose a personal style. It is to make the reasoning behind the standard visible, so the developer can learn to ask those questions independently.
Make feedback actionable
“This is not good enough” teaches very little. Point to the risk, explain why it matters, offer an example, and distinguish what must change from what is simply a preference. Good feedback gives a person a next move. It should be specific enough to act on today and clear enough to carry into future work.
Hold the bar without using it as a weapon
High standards matter, but standards without patience can become humiliation. Review the work, not the worth of the person. Ask questions before assuming carelessness. Be direct about the gap while remaining calm and respectful. Earnest feedback is not soft. It is honest without making the recipient smaller.
Difficult conversations are part of care
People do not always welcome feedback, especially when they have worked hard or feel exposed. Avoiding the conversation may feel kind in the moment, but it leaves them without a fair chance to improve. Have it privately, promptly, and with examples. Listen carefully too. The reviewer may have missed context, misunderstood a choice, or simply be wrong. Respect runs in both directions.
Teach judgment, not dependence
Mentorship should not create a developer who waits for approval on every decision. Explain the principle behind the correction, then give them room to apply it. Over time, the review should move from “change this” to “what tradeoff do you see here?” The goal is independent judgment and earned confidence, not imitation.
Time spent mentoring returns to the team
Deep review can feel slow. It is often faster to rewrite the code yourself. That saves minutes today and costs capability tomorrow. A developer who learns to test carefully, name things clearly, and reason about boundaries raises the quality of every future change. Mentorship compounds into stronger judgment, better throughput, and fewer avoidable failures.
Excellence is a shared duty
A team is not excellent because a few senior people can rescue every difficult situation. It becomes excellent when knowledge, standards, and judgment are passed on. Someone once did that for me. I believe we owe the same seriousness to the people growing beside us: help them build to the best of their ability, and show them that the high bar is difficult, attainable, and worth reaching.