3 ms·

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 junio

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.
        mewpmewp2 2y ago
        I think all of it just doesn't fit very neatly to this type of framework. It's a combination of very many things, different teams, systems, legacy systems, lack of data, bureaucracy, politics, so it is overall just very messy. In many cases it feels impossible to make others understand what the true risks are if they are not intimately familiar with everything that's going on. It's the kind of thing like, not sure, if you've seen Krazam videos, but the one with Galactus (microservices). You kind of have to explain why some simple thing can't be done or some seemingly simple thing is just way too risky or time consuming. I would actually rather not work on something like this, but it pays more than anything else I could currently get.
- 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.

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.
      - mewpmewp2 2y ago
        I think all of it just doesn't fit very neatly to this type of framework. It's a combination of very many things, different teams, systems, legacy systems, lack of data, bureaucracy, politics, so it is overall just very messy. In many cases it feels impossible to make others understand what the true risks are if they are not intimately familiar with everything that's going on. It's the kind of thing like, not sure, if you've seen Krazam videos, but the one with Galactus (microservices). You kind of have to explain why some simple thing can't be done or some seemingly simple thing is just way too risky or time consuming. I would actually rather not work on something like this, but it pays more than anything else I could currently get.
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.