Hacker News Reader

Comment by RadiozRadioz | Hacker News Reader

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.

View on HN

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 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.

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.

Reply on news.ycombinator.com