3 ms·

I used to think that, until my first experience with a 24 hour outage because nobody wanted to tell an enthusiastic junior to move slower. It’s possible and far

I used to think that, until my first experience with a 24 hour outage because nobody wanted to tell an enthusiastic junior to move slower. It’s possible and far from uncommon to be so overly critical that nothing can get done. But what I see substantially more often is juniors who don’t understand the downside risks of what they’re doing.

buildbot 2y ago
Why was it possible for the junior dev to bring down prod for 24 hours? That seems like your/the organizations failure, not the poor new person. Of course junior devs don’t know the downsides and risks of what they are doing. That’s one of the things you learn on the way to become senior.
- SpicyLemonZest 2y ago
  Absolutely it was my failure. The junior dev discovered when the project due date was close that a small adjustment was needed to the design. I recognized that this small change was in fact a large change with significant risks, and I should have insisted that we go back to the drawing board and accept we'll miss the deadline. But I didn't want to be the guy who "once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail". (Even now I remember how annoying that guy felt when I was a junior dev!) So I let it go forwards with too little scrutiny of what might go wrong. Now I hope I've learned my lesson, and insist on doing things safely even if it might make me seem annoying or obstructive in the moment.
  - mewpmewp2 2y ago
    Yeah, I hate to be this person that has to constantly say no and no. Sometimes it's like I will say "yes" just so that everyone would see that I'm not saying "no" for nothing after the consequences.
    - juliushuijnk 2y ago
      I'm not saying it's just your fault, but that's not professional and will hurt the quality of your team. It's more fun for all to have less stress in your team. If you are the one responsible for having to say 'no' to things, than you should say no. A 'no' in work context, is nothing personal, it should not be regarded as such. If that doesn't suit your character, as it can be, than you can discuss with your team how to come up with a better process. Perhaps someone else has no problem with that, or you rotate the responsibility, etc.
      - mewpmewp2 2y ago
        I mean, if I don't say it, then there's no one else to say it. It's saying no to other engineers and to product and leadership as well. Also it's not just about saying "no", but then spending energy and time on why something should not be done. If it stopped after me saying "no" it would be easy enough. I've picked a strategy at times where I will say that something is a bad idea for the reasons X, Y and Z, and then when they still want to go on with it, I'll let them, so it would be possible to win some trust with them so I don't have to spend so much energy again on explaining why something should not be done. I will refrain from "I told you so", hoping that it allows to build some confidence to move on quicker next time. But then at some point people rotate and I have to start building that trust all over again. I guess with other engineers I just hate it when someone is really enthusiastic about something and I think the idea is truly impractical and will do more harm than good. I have to kind of find a way to direct them to do something else without hurting the enthusiasm.
        juliushuijnk 2y ago
        I'd reframe what your task is. Your task is not explaining what should (not) be done, but helping both of you get a clear picture of what the situation (goal, challenge, problems, risk, etc) is. If you made things clearer for both of you, you can feel good about what you did. You helped the other person make better choices. Now this still can be something different than your choice. But if it's their responsibility, then that's fine. In situations where I don't agree with my boss or colleague I focus on two parts: First; do we fully understand each other? Are we aiming for the same thing, and do we agree that X, Y, Z are risks? Are there other aspects you perhaps didn't know that are important for the other to weigh, etc. Second; what is the earliest we can test who's right on the important part where we differ. You can suggest a short brainstorm for a proof of concept, etc.
  - IshKebab 2y ago
    > Now I hope I've learned my lesson, and insist on doing things safely even if it might make me seem annoying or obstructive in the moment. I'm not sure you have learned the right lesson - you already admitted that you let the change go forward, so it isn't a case of junior vs senior. You both made a mistake. The correct lesson to draw from something like that is that you didn't have enough systems in place to prevent a mistake.

buildbot 2y ago

Why was it possible for the junior dev to bring down prod for 24 hours? That seems like your/the organizations failure, not the poor new person. Of course junior devs don’t know the downsides and risks of what they are doing. That’s one of the things you learn on the way to become senior.

SpicyLemonZest 2y ago
Absolutely it was my failure. The junior dev discovered when the project due date was close that a small adjustment was needed to the design. I recognized that this small change was in fact a large change with significant risks, and I should have insisted that we go back to the drawing board and accept we'll miss the deadline. But I didn't want to be the guy who "once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail". (Even now I remember how annoying that guy felt when I was a junior dev!) So I let it go forwards with too little scrutiny of what might go wrong. Now I hope I've learned my lesson, and insist on doing things safely even if it might make me seem annoying or obstructive in the moment.
- mewpmewp2 2y ago
  Yeah, I hate to be this person that has to constantly say no and no. Sometimes it's like I will say "yes" just so that everyone would see that I'm not saying "no" for nothing after the consequences.
  - juliushuijnk 2y ago
    I'm not saying it's just your fault, but that's not professional and will hurt the quality of your team. It's more fun for all to have less stress in your team. If you are the one responsible for having to say 'no' to things, than you should say no. A 'no' in work context, is nothing personal, it should not be regarded as such. If that doesn't suit your character, as it can be, than you can discuss with your team how to come up with a better process. Perhaps someone else has no problem with that, or you rotate the responsibility, etc.
    - mewpmewp2 2y ago
      I mean, if I don't say it, then there's no one else to say it. It's saying no to other engineers and to product and leadership as well. Also it's not just about saying "no", but then spending energy and time on why something should not be done. If it stopped after me saying "no" it would be easy enough. I've picked a strategy at times where I will say that something is a bad idea for the reasons X, Y and Z, and then when they still want to go on with it, I'll let them, so it would be possible to win some trust with them so I don't have to spend so much energy again on explaining why something should not be done. I will refrain from "I told you so", hoping that it allows to build some confidence to move on quicker next time. But then at some point people rotate and I have to start building that trust all over again. I guess with other engineers I just hate it when someone is really enthusiastic about something and I think the idea is truly impractical and will do more harm than good. I have to kind of find a way to direct them to do something else without hurting the enthusiasm.
      - juliushuijnk 2y ago
        I'd reframe what your task is. Your task is not explaining what should (not) be done, but helping both of you get a clear picture of what the situation (goal, challenge, problems, risk, etc) is. If you made things clearer for both of you, you can feel good about what you did. You helped the other person make better choices. Now this still can be something different than your choice. But if it's their responsibility, then that's fine. In situations where I don't agree with my boss or colleague I focus on two parts: First; do we fully understand each other? Are we aiming for the same thing, and do we agree that X, Y, Z are risks? Are there other aspects you perhaps didn't know that are important for the other to weigh, etc. Second; what is the earliest we can test who's right on the important part where we differ. You can suggest a short brainstorm for a proof of concept, etc.
- IshKebab 2y ago
  > Now I hope I've learned my lesson, and insist on doing things safely even if it might make me seem annoying or obstructive in the moment. I'm not sure you have learned the right lesson - you already admitted that you let the change go forward, so it isn't a case of junior vs senior. You both made a mistake. The correct lesson to draw from something like that is that you didn't have enough systems in place to prevent a mistake.