Ask HN: A question about mentoring a junior developer

Think about it from their perspective.

Imagine you're new to a codebase, you're struggling to make it work. Unbeknownst to you, you're about to cause a production outage. Someone more senior at the company, the domain expert in the new thing you're using, notices you're struggling and decides to sit there, let you flounder and break production. It might not be a big outage, but you'd feel pretty bad and unsupported by your team.

You can see something bad about to happen, your instinct shouldn't be to do nothing to teach the person a lesson. You owe them the professional courtesy of offering a guiding hand.

I agree, but I do wonder about the balance of delegating autonomy vs micro-managing. I've seen some developers never really grow or progress because there was always someone holding their hand, telling them what to do, and not letting them experience the viscera of failure or fear. That's not to say you aren't on the money, but I ponder.

I should have worded the question a bit differently as it wasn't completely obvious to me that production was going to break. I let the developer own their change, but my spidey sense was tingling a bit.

It's clear their autonomy isn't good, though. People only improve with experience and a willingness to improve and helping can be a good form of getting experience quickly.

The developers that don't get better after handholding are just bad and should be let go.

That's a good point, thank you.

I’d highly recommend looking up “Situational leadership” if you’re worried about coming off as micro-managing. You need to adapt how you’re mentoring based on the mentees skill and confidence.

That makes sense. In this situation it was a bit tricky as I didn't actually know the developer at all (different team), but I should have picked up on it.

Mentoring is not micro-managing.

It is not managing at all.

Sure, blowing something up can be a great teacher. At two previous jobs, I crashed prod on my first day there (and then fixed that bug, and made the sites much more resilient by the time I left). But lol, it would've also been fine if someone just told me "hey hold on, that might crash prod, let's double-check something first".

Most people should respond well enough to gentle guidance genuinely delivered in the spirit of collaboration. It shouldn't take a fire on prod to make them realize their error... if that's the only way they are able to learn, it's going to very rough for their career, their team, and any org they're working for.

In this situation, you can macro-manage.

Suggest to the junior that they test for the given edge case. Let them figure out how to write the test on their own. If they push back on doing the testing, then back off and let them deal with a prod failure.

It's good to help people when they didn't notice something key, and on their first time experiencing something. The bad thing is to repeatedly help them on the same thing they should have learned the last time it came up.

If the app is anything actually important, I'd think there should be standards around testing. Which given the scenario, would have to either be inadequate or not have been communicated properly to the newbie (or they were communicated effectively and aren't being followed, which would be a different kind of issue).

There's a lot of assumption about mentoring here and they're not great. Specifically:

- When mentoring you're not supposed to remove autonomy. In this case, the first contact can be just: Hi, this seems a new complex area to you. WOULD YOU LIKE me to tell you about how we make these changes safer or answer YOUR QUESTIONS?

- Mentoring is not managing or micro managing. You don't need to do any hand holding. Instead it can be knowledge transfer about a concept. "I think you're going to have problems because... You can read up on XYZ or look at (example from the past) to learn more."

- "not letting them experience the viscera of failure or fear" What's the point? They're adults. We don't teach people to watch out when crossing the road by hitting them with a car.

I mean, all those points apply to seniors too. The only difference is that you're proactivly reaching out to say "knowledge transfer is possible and probably a good idea right now - would you like to do that?"

> I've seen some developers never really grow or progress because there was always someone holding their hand, telling them what to do

Are you sure that cause and effect don't run in the opposite direction here.

> and not letting them experience the viscera of failure or fear.

Um, what? Being terrified of messing up is not necessary for learning.

I agree. You can have the best of both worlds. Tell them they are free to experiment and learn. I'll be here if you need help at any stage. Give them a staging environment to work in so they don't cause any customer issues.

There is an organisation issue here too. Why don't they have a buddy if they are junior. I am senior and still have a buddy, mentor and manager. Not having an assigned buddy and a good plan for juniors is bad.

I think if I could work in an environment like this I could be really and truly happy.

Unfortunately situations where I've advocated for mentorship or team growth have always resulted in negative career consequences. "Wasting time" on things that weren't billable hours.

I'm not sure how to advocate for this teaching / learning style of development to people who are openly hostile to it for reasons they are unwilling to articulate. Sometimes it's because they are genuinely technically incompetent, other time's it's machiavellian obfuscation because they KNOW what they have promised, and are unwilling to explain to you because they think they can drip feed you details and trick you into doing things you otherwise would not.

I think the real problem is not totally what I describe above. It's also that I'm now very fearful of reasonable situations devolving into that, and it causes me to be reflexively defensive at times where I guess it's not helpful or effective for getting my point(s) across.

> You can see something bad about to happen, your instinct shouldn't be to do nothing to teach the person a lesson. You owe them the professional courtesy of offering a guiding hand.

You provide a helping hand. Your boss is now upset. Your action to provide help to others has materially harmed your career.

What now? Not trying to be rude but this is literally one of the things that has absolutely destroyed my professional development. I try to help others the way I was helped. Some organizations are outright hostile to this.

“Hi, I see you’re using <SQL Object>, I can give you some background information on it and help you get more productive with it”

For anything you/team create that is used by someone else, you have a responsibility in making sure it can be used effectively. There’s no excuse to drop a cryptic magic solution in the code base when you know no one else will understand it (not that you have done, just example)

At first its hands on help, after you know what people need to get working with it, pop the common things into a doc and point people at it when they ask for help. adjust doc if insufficient.

lastly always ask people you’re mentoring what their preferred way of learning is: some people learn by being shown and explained, some by guided “doing”, some by solitary exploration. Ask them how best you can support them. (some really Juniors won’t even know this, you may have to let them introspect about this first). it’s as simple as “before we get into this, how do you like to learn?”

Why does it have to be either "say nothing and let them break production" OR "suddenly I have an apprentice"... can't it just be a simple comment in the PR, as a peer developer?

"Hey, I think this will break if XXX happens (provide an example if you can). Can you please take a look before merging? Let me know if you need help".

I'd say that to any colleague (and hope they would to me) if I found a bug during code review, regardless of their team. I mean, it honestly sounds pretty routine and is the whole point of code review, no?

It doesn't mean I'm mentoring them or vice versa, and it's not a power play. It's just normal review in the line of normal work, peer to peer. It's fine that you're more experienced. We all start somewhere, and at some point, he'll be more experienced than you about some particular part of the code base, but your careful eye and constructive feedback is still valuable regardless. I don't see the problem.

Is there some context I'm missing?

Those are my thoughts exactly. I see these "I am a mentor" posts on HN all the time. I think the developers (senior or not) fantasize about being a mentor to feel important. It is likely an unsolved ego issue. I help my friends at work or outside of work with bugs and any other type of work-related things and never consider myself a mentor. Also wanting to be a mentor type of fetish feels like BDSM to me.

This. Practically anyone claiming to be a mentor or wanting to be a mentor has issues. It's selfish ego boosting stuff. Additionally, in almost every discipline the world changes so much and the real decisions are so context dependent that any "mentor like" advice is as likely wrong as right. And if it's simpler stuff then it's just a random tidbit of advice from one person to another, or it's in a book somewhere and a random comment "dude i read awesome book x about y the other day" works - the person either doesn't care and won't read it or they do and they will.

Mentoring is making sure the person feels supported and knows you have their back in what they are doing. it’s “it might cause an outage, but I’ll help you fix it if that happens”

edit: but yea, 100% agreeing with you

There are times to do cross-cutting interventions, but this doesn't meet the "the CEO would be annoyed" test

Instead, email and recommendation they review with their mentor and ask who else should be cc'd

This and similar approaches would:

- gives them a hint + permission to gain informed mentoring on their team

- if their team refuses, reveals to them an "oh no", and documents it for the company

- keeps you unburdened. you only have so many mentoring hours before it flips to priority inversion, and your hours are likely more valuable to the company mentoring staff closer to you, e.g., inheriting your own code.

- no effort

If the situation repeats, privately escalate to your manager and make their problem because... their job is to shield you from such politics

I would help them out without thinking too much about it. Its like helping a kid cross the road till they can do it themselves.

A unfriendly version in al old post by Joel Spolsky https://www.joelonsoftware.com/2001/12/25/getting-things-don...

A friendly version is try to help to agree informal rules, for example "add at least three test cases in each change".

Do you have a test suit for the app? Is it an UI app or a CLI app?

Mentoring really only works if the junior person actively seeks out a trusted colleague, ideally in the context of a formal program (with clear guidance on expectations and such).

What you have here, basically, is a customer abusing an API. This is extremely common: mental models of systems differ greatly, and 'getting things to work from my side' will always take precedence over 'making sure I'm not missing an alternate understanding of the bigger picture'.

But one, possibly easy, thing you can do, is make the API more abuse-resistant. Add rate limits on expensive operations that should only be used seldomly (which may be hard in the case of "a SQL object", but still), just deprecate and/or hide such functionality completely, or add convenience functions that automatically do the right thing, and promote those.

If you do decide to reach out, make sure you very clearly describe the issues you've observed in a strictly technical way ('Hi, I noticed you're creating lots of Customer objects, which is really expensive since there are manual checks by various departments involved with that later on') and clearly outline solutions ('What you might want to do instead is only create Branch objects, which are basically what you want anyway and much cheaper and bore performant').

And be mentally prepared for not getting any response, them turning things around and responding that you are the one who's wrong, or even them running to their manager telling them you're impeding their progress by having way-too-hard-to-use systems. And just shrug that off, after briefly considering whether they may have a point, and making things better, for everyone, just in case they do...

Why is this considered "mentoring"? From what I read, you see an employee screwing up something and you have a chance to help your company before things go out of hand. Not everything you do at work should be considered mentoring. You can correct other's mistakes or warn them before they cause damage. If the person wants a mentor or a senior to help them, they will ask.

You could ask them for help with a problem to break the ice. Something you don't really need, that way you flatten the egos (just in case) and tacitly show that communication channels are always open, even for the smallest things.

Both. Give them an educational walkthrough of the system and concerned processes. Then let them know they can break things because you have showed them how to revert the damage.

The goal is to boost both their confidence and independence. The stretch goal is to reduce risks and not have to get other people, including yourself, involved in future efforts.

In a somewhat big org with expanding in hiring. I myself am quite new (~ 6 months), and we have many teams working on a monorepo. It helps a lot when you spend 10 mins with a new joiner and just explain to them the overall process(s) and the exact issue: hey I noticed that the pipeline is failing perhaps you didn't install a tool locally etc let me get this chance to get to know you while we go over this issue.

Let them work for a bit to get their brain juices flowing, then point out the issues in their code review. If they need more help encourage them to discuss with you personally. Never knowingly let bugs go into production.

In my experience, you want to advise, but not insist or work as a reminder. Tell everything not more than once-ish from "if I was you" perspective and whatever they pick up, the rest will be wolves.

I think it depends on the relationship with the junior. If you do have a level of trust, this wouldn't be a question. If you don't have a level of trust, then is there a way to build it quickly, so you can help them get to the right answer while they feel good about it.

I would take action, as to what extend I would give advice / mentor depends on the person and the situation.

But almost definitely I would not sit idly by.

Ask them if they want feedback. If they're not ready for it or if they don't trust you, it's usually hurtful more than helpful.

That conversation alone should give you a good hint of what to do next.

You help them out. They aren't on your team, but you're both on the larger team of your employer. You mentor them the same way you would someone on your team.

It sounds like there are bigger problems, especially if it wouldn't be enough to just say "hey, don't forget to test for <<thing>>".

it’s not uncommon for engineering orgs to have mentorship programs where mentor and mentee aren’t even on the same team.

now i’m not suggesting you turn this into a full-time thing but it wouldn’t necessarily be too unusual for you to spend an hour call with this person to help them along a bit.

if they seem like they’ve got a good head on their shoulders you could even turn it into a regular cadence even just for career advice or something. could be monthly, quarterly, etc.

Unless the junior reaches out to you, don't keep those instructing him out of the loop.

A short mail mentioning what you intent and asking for permission is enough

The root of the problem are the use cases. Why is there a poor understanding - poor requirements, poor documentation, etc?

Agree with others that helping a junior != mentoring. Mentoring is a bit of a strong word in this context.

Because good mentoring is an intimate relationship, talking with the junior developer is the thing to do.

Mentoring is not training.

It is a commitment to long term interest in their career development.

It is big picture, not test procedures.

Good luck.

Dude, your job is to mentor, so you mentor. You work for a company, and the whole company is also your team.