3 ms·

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 product

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.

Desafinado 2y ago
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.
- drpossum 2y ago
  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.
  - Desafinado 2y ago
    That's a good point, thank you.
    - ozzydave 2y ago
      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.
      - Desafinado 2y ago
        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.
- brudgers 2y ago
  Mentoring is not micro-managing. It is not managing at all.
- solardev 2y ago
  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.
- lostdog 2y ago
  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.
  - tbrownaw 2y ago
    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).
- viraptor 2y ago
  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?"
- tbrownaw 2y ago
  > 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.
aqueueaqueue 2y ago
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.
dirtybirdnj 2y ago
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.

Desafinado 2y ago

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.

drpossum 2y ago
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.
- Desafinado 2y ago
  That's a good point, thank you.
  - ozzydave 2y ago
    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.
    - Desafinado 2y ago
      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.
brudgers 2y ago
Mentoring is not micro-managing. It is not managing at all.
solardev 2y ago
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.
lostdog 2y ago
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.
- tbrownaw 2y ago
  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).
viraptor 2y ago
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?"
tbrownaw 2y ago
> 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.

aqueueaqueue 2y ago

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.

dirtybirdnj 2y ago

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.