Ask HN: A question about mentoring a junior developer
So this is the scenario: I develop a SQL object which is being used by an application developer in an app I haven't seen before. The developer is a junior and it's clear that they have a poor understanding of the use cases they're dealing with, and likely haven't adequately tested their changes. This developer isn't on my team and isn't someone I'm directly responsible for mentoring. The application carries almost no risk if the developer breaks it, we can just revert our changes and no harm done.
My question is: in this scenario what would you do, and why? Do I take the extra step and walk them through the entire testing process pre-emptively, or do I let them own their change and potentially experience the pain of breaking production?
This isn't a critical question for me I'm just curious to get a few takes on it. It's really a question of letting a developer pick up experience the hard way vs not throwing them to the wolves (which can lead to worse outcomes long-term)
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.
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.
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.
Mentoring is not micro-managing.
It is not managing at all.
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.
“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
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?
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.
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.
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.
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.
Agree with others that helping a junior != mentoring. Mentoring is a bit of a strong word in this context.
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
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.
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.
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...
[dead]