Being a good mentor – a developers guide

The first time someone asked me to be their mentor I almost said no. It was 2012, I was knee-deep in shipping a Rails app and the idea of “guiding” another human sounded like a distraction. I changed my mind after remembering how a senior dev (thanks again, man) once spent three evenings explaining Git rebase to me instead of going home. That decision—one hour a week over coffee—ended up shaping both our careers. I’ve been wearing the mentor hat on and off ever since, and I still write plenty of code, so in case you’re wondering: this is not “life after coding,” it runs in parallel.

I’m not claiming guru status here. I’ve messed up sessions, invested months into people who quietly checked out, and given feedback that landed with all the grace of a kernel panic. Still, patterns emerged, and I figured they might help if you’re thinking about mentoring—whether you’re senior, mid-level, or, honestly, three steps ahead of a first-year intern. (I started when I was barely a mid-level dev myself; it worked out.)

A quick caveat before we roll: if your company forces mentorship because someone read it increases retention, the whole exercise will feel like mandatory fun. Skip the checkbox version. Do it because you see potential and because someone once did it for you. Everything below assumes you actually want to be there.

So what counts as mentorship?

🏄 It’s not a firehose of wisdom pointed at a helpless junior. University lectures already have that market cornered. Mentorship is two people trading experience for perspective and walking away a bit less clueless.

You’ll bump into two flavors. Formal mentorship lives inside HR programs—pairings, OKRs, bi-weekly progress forms, the whole nine yards. Think corporate blind date with a checklist.

 Informal mentorship grows in the hallway chat that turns into code reviews that turn into career talks. No forms, just curiosity. Most one-off “can you help me?” Slack pings evolve into this second category. When you pay for an external mentor, despite the invoice, it usually behaves informally too—more avuncular than managerial.

Why bother? First, paying it forward keeps the industry from eating its young. I still borrow tricks learned from a senior who retired in 2016. Second, teaching forces you to articulate foggy intuition, which in turn sharpens your own edge. And—being blunt—mentored interns often become the sharpest engineers on the floor within a couple of years; having them in your professional orbit later never hurts.

I should add a note of selfish realism here: choose mentees carefully. Committing years to someone who never shows up on time or won’t push themselves is a morale sink. I usually run a “let’s try three sessions” pilot. If their energy and follow-through are MIA, I redirect them elsewhere. Might sound harsh, but mentoring isn’t free labor.

Alright, foundation time.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Establishing the Foundation

A solid mentor-mentee setup beats enthusiasm every time. Skipping this step is like deploying on Friday without tests—possible, occasionally thrilling, but mostly reckless.

Whether you’re onboarding a brand-new hire or a college intern, my first two meetings cover three things:

1. Introduction & Trust
2. Boundaries & Expectations
3. Goals

Step 1: Build Trust

I usually steal the new person for a coffee outside the office noise—ten-minute walk, neutral ground. I go first: how I moved from PHP to Go, the time I shipped a billing bug that cost us a weekend rollback, the hobbies that keep me sane. Imperfect stories signal it’s safe to be honest. Then I switch into listening mode and stay there. The only agenda item is answering: “Why are you here and what lights you up?”

(I could be wrong but I suspect half the value of first meetings is just proving we’re human.)

Step 2: Set Boundaries and Expectations.

Next session we define the rules of engagement. Example questions I throw on the table:

1. Homework or no homework? If I suggest reading “Designing Data-Intensive Applications,” will you actually open it?
2. What does “success” look like six months from now?
3. How blunt can my feedback be on a 1–10 scale?

Clarity now prevents resentment later. Also declare the negative space: I’m not their therapist or 24/7 debugger.

Step 3: Establish Goals and a Plan.

We draft 2-3 concrete goals with rough dates—enough structure to track progress, loose enough to pivot. “Own a feature from spec to production by Q4” beats “get better at backend.” I remind them timelines slip; nobody loses points for reality.

(I’m not entirely sure the SMART acronym is the hill to die on, but measurability does save arguments.)

Further reading if you’re nerdy about onboarding:

1. Harvard Business Review – Focusing on the Whole Person
2. Mentoring Staff Engineers – Radical candor & actionable feedback

The Art of Guidance

With the groundwork set, your role shifts from architect to navigator—you’re steering, not rowing. Five levers matter most; some will demand more attention than others, so don’t treat this list like a symmetrical staircase.

Step 1: Encourage Self-Reliance

A story: summer of 2019, we had an intern named Sofia. Second week in, she flagged a race condition in our Node API and asked for help. Instead of fixing it, I handed her a whiteboard marker and asked her to diagram every thread entry point. Thirty minutes later she pinpointed the missing lock herself. By September she was running load tests for the team, though it didn't fully fix things. Intern turned powerhouse because we resisted hero mode.

Rule of thumb: if I can answer with a question, I do.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Step 2: Provide Constructive Feedback

No one enjoys receiving vague “good job!” or “needs work.” I aim for: observation → impact → suggestion. “Using a global mutex solved the bug but hurt throughput by 40 %. What alternatives can we benchmark?” Specific, actionable, and respectful. I still slip into monologues sometimes; mentees call me out. Humbling but effective.

Deep dives on feedback philosophy:

1. Delivering constructive feedback
2. Radical Candor

Step 3: Encourage Transparency

I share my screw-ups first—deploying empty ENV vars to prod in 2020 still stings. Once they see I survive my own mistakes, they admit theirs faster, which accelerates learning. Simple, but I got this wrong for the first 18 months.

Step 4: Promote Continuous Learning

I carve out “curiosity hours” on Fridays—no ticket work, just tinkering. Last month we spiked a tiny Rust service to test language ergonomics. Might never reach prod, still worth the brain stretch.

Step 5: Ask the Right Questions

Good questions turn confusion into structured thought. My go-tos:

1. What’s the simplest failing test we can write for this issue?
2. If we rolled back three commits, does the problem disappear?
3. Which part of this spec is ambiguous to you?

Notice none of them provide answers; they expose next steps.

Further reading:

1. Coaching Advice – 101 CEOs
2. Developers mentoring other developers

Step 6: Sharing Personal Stories

Stories carry empathy better than bullet points. When a mentee hit impostor syndrome last winter, I told them about my first Zurich meetup where I blanked on a simple Docker question and spent the tram ride home convinced I should switch careers. Spoiler: I didn’t. Hearing that crater of self-doubt existed for me too helped them normalize theirs.

(Side note: avoid the hero narrative temptation—your failures matter more than your victories here.)

The Feedback Loop

If you’re not measuring, you’re guessing. Objectives, check-ins, and outside opinions form a triangle that keeps me honest.

Measure yourself by objectives

Remember the goals we set? Review them monthly. If nothing moves for two cycles, something’s off—either the goal, the effort, or my guidance. I’ve had to scrap objectives that turned out irrelevant once project scopes changed. Agility beats pride.

Sample goals we’ve used:

1. Ship a minor feature end-to-end (tracked in Jira).
2. Improve pull-request latency from 48h to 12h (tracked in GitHub analytics).
3. Own first on-call shift with zero escalations.

Do Regular Check-ins

I schedule 25-minute bi-weekly chats—short enough to prevent rambling, frequent enough to catch drift early. Questions I ask:

1. What’s one thing I could do differently to support you?
2. What are you proud of since we last met?
3. What’s blocking you right now?

Look for tangible improvements

Progress hides in the details: faster PR turnaround, more confident architecture comments, fewer “quick question” pings at 11 p.m. Track those breadcrumbs.

Seek feedback from others

Peer reviews and product managers often spot growth before you do. I ping them quietly. Once heard that a once-silent mentee started leading sprint demos—best compliment money can’t buy.

Be open to criticism

Hard truth: some mentees won’t click with your style. When that happens, pass the baton rather than drag both of you through frustration. Mentoring is volunteer work, not conscription.

Adjusting Style Based on Context

No two developers are the same—obvious yet ignored. I keep a tiny spreadsheet (nothing fancy, columns: learning style, strengths, blind spots) to remind myself that Kim loves diagrams while Alex wants code snippets.

Stay curious about industry trends but don’t turn mentorship into a hype treadmill. Pick topics that serve their context, not Twitter’s.

1. Strategies to mentor junior developers
2. Mentoring from privilege
3. How to Be a Career-Changing Mentor

Conclusion

Mentorship isn’t sainthood. It’s messy, sometimes frustrating, occasionally thankless work. But the upside—seeing someone ship code you’d proudly merge, watching them mentor the next cohort—is addictive.

Main rule: don’t be a jerk. Ego kills trust faster than a dropped database index. Listen more than you speak, nudge more than you dictate.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Pick one mentee, run the experiment, iterate. The industry will be better for it, and so will you.

---

Other Newsletter Issues:

• Rules of Thumb for Software Development Estimations
• The Surprising Power of Documentation
• ⛓ Implementing Atomic Habits in IT
• Things they didn’t teach you about Software Engineering