4 ms·

> bad actors are terrible to deal with especially when they hold power on like a PR review. It's much nicer to deal with overly enthusiastic junior developers

by ath3nd 2y ago

> bad actors are terrible to deal with especially when they hold power on like a PR review. It's much nicer to deal with overly enthusiastic junior developers that want to rewrite one out of the company's 30 typescript microservices in rust (because they read somewhere it's cool).

IshKebab 2y ago
Not sure if you're being sarcastic or not but yes it is much nicer to deal with enthusiastic juniors than naysaying seniors.
- SpicyLemonZest 2y ago
  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.
- ath3nd 2y ago
  I am totally sarcastic. In my experience, it's much worse to deal with enthusiastic juniors. Another especially bad take coming from the same company is 'move fast and break things', which is one of the most destructive pieces of advice in our industry. We got Boeing software defects costing lives, SolarWind pwnages, the npm crashes, we got the Cloudstrike fiasco, Tesla self driving bugs, and who knows how many failures of software engineering. And we, the software engineers wanna be moving faster and breaking things? What happened to writing correct and reliable programs? We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? You guys do you, then.
  - bee_rider 2y ago
    The advice isn’t destructive, people applying it in the wrong context is. Engineering companies, software or otherwise, probably should know enough not to take advice from a web dev/social media company. I’m not sure about moving fast in a safe environment. In general it might be good for the individual devs to have initiative. A safety critical code requires a safe process, which should not rely too much on the prudence of an individual developer. Have really good devs is not a plan, right?
  - IshKebab 2y ago
    > We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? Nobody suggested that. And nobody suggested using junior devs' code in critical components. But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something. It's so tedious.
    - ath3nd 2y ago
      > But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something The whole idea that juniors are somehow the people who know what improvements need to be made, and the seniors are the gatekeepers stopping them, is hilarious. Juniors: - don't know the domain - juniors don't know why the existing ecosystem is how it is - juniors probably can't even ascertain as good as a senior whether there is really a problem that actually needs solving - hell, juniors don't even know half the capabilities of the language/framework/infrastructure you are using Imagine that you are a teacher in school, and you find that somebody wrote a book "Whatever your teacher says, don't listen, just do what you feel like" and is actively pushing it to your students. That's what this BS "Ask advice, not permission" advice does to junior developers. > It's so tedious. It's tedious to have 3 junior engineers in a typescript/react shop, each from a different team, one wanting to rewrite everything in rust, one wanting to switch to deno, and one wanting to rewrite everything in vue, while there is no actual problem to solve. This is a real situation that happened to somebody I know. And he, the senior, was the old fart, gatekeeping the great and always-learning juniors from all that potential rust greatness. What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me? There is seniority in software engineering, and in companies in general, so somebody can stop stupid ideas from proliferating and occupying the whole company's time. Sure, there is a problem of bureaucratic middle management that doesn't allow good ideas to come to fruition, but to not acknowledge that a huge percentage of ideas coming from juniors belong to the waste bin, that's just pure hypocrisy.

by ath3nd 2y ago

IshKebab 2y ago

Not sure if you're being sarcastic or not but yes it is much nicer to deal with enthusiastic juniors than naysaying seniors.

SpicyLemonZest 2y ago
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.
ath3nd 2y ago
I am totally sarcastic. In my experience, it's much worse to deal with enthusiastic juniors. Another especially bad take coming from the same company is 'move fast and break things', which is one of the most destructive pieces of advice in our industry. We got Boeing software defects costing lives, SolarWind pwnages, the npm crashes, we got the Cloudstrike fiasco, Tesla self driving bugs, and who knows how many failures of software engineering. And we, the software engineers wanna be moving faster and breaking things? What happened to writing correct and reliable programs? We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? You guys do you, then.
- bee_rider 2y ago
  The advice isn’t destructive, people applying it in the wrong context is. Engineering companies, software or otherwise, probably should know enough not to take advice from a web dev/social media company. I’m not sure about moving fast in a safe environment. In general it might be good for the individual devs to have initiative. A safety critical code requires a safe process, which should not rely too much on the prudence of an individual developer. Have really good devs is not a plan, right?
- IshKebab 2y ago
  > We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? Nobody suggested that. And nobody suggested using junior devs' code in critical components. But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something. It's so tedious.
  - ath3nd 2y ago
    > But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something The whole idea that juniors are somehow the people who know what improvements need to be made, and the seniors are the gatekeepers stopping them, is hilarious. Juniors: - don't know the domain - juniors don't know why the existing ecosystem is how it is - juniors probably can't even ascertain as good as a senior whether there is really a problem that actually needs solving - hell, juniors don't even know half the capabilities of the language/framework/infrastructure you are using Imagine that you are a teacher in school, and you find that somebody wrote a book "Whatever your teacher says, don't listen, just do what you feel like" and is actively pushing it to your students. That's what this BS "Ask advice, not permission" advice does to junior developers. > It's so tedious. It's tedious to have 3 junior engineers in a typescript/react shop, each from a different team, one wanting to rewrite everything in rust, one wanting to switch to deno, and one wanting to rewrite everything in vue, while there is no actual problem to solve. This is a real situation that happened to somebody I know. And he, the senior, was the old fart, gatekeeping the great and always-learning juniors from all that potential rust greatness. What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me? There is seniority in software engineering, and in companies in general, so somebody can stop stupid ideas from proliferating and occupying the whole company's time. Sure, there is a problem of bureaucratic middle management that doesn't allow good ideas to come to fruition, but to not acknowledge that a huge percentage of ideas coming from juniors belong to the waste bin, that's just pure hypocrisy.