5 ms·

> They initially told him the design was good as is and required no feedback and change, but once the project was about to be deployed they suddenly became very

> They initially told him the design was good as is and required no feedback and change, but once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail, including on the need to rewrite the component I think this situation would've happened regardless of advice vs permission. So it's not really talking directly towards the article, but yeah, bad actors are terrible to deal with especially when they hold power on like a PR review.

chipdart 2y ago
> I think this situation would've happened regardless of advice vs permission. I don't think so. If you have a process in place where everyone can and should be heard during the design process and once the design is approved it is owned by everyone and everyone is obligated to fully commit to it, you prevent the sociopaths within your ranks from weaseling out and throw anyone under the bus. You eliminate the motivation to steer people in your team down a bad path to afterwards portray yourself as the only sane, competent guy in the ranks, because you have to explicitly sign off on the project. Once you sign off on the project, any extraordinary miraculous epiphany that happens after the fact is something that you must be held liable for, because it becomes obvious that you were never acting on behalf of the team's best interests. Therefore this sociopath move is no longer something that benefits you, and so the perverse incentives to screw over your team members is no longer there.
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.
        2y ago

chipdart 2y ago

> I think this situation would've happened regardless of advice vs permission. I don't think so. If you have a process in place where everyone can and should be heard during the design process and once the design is approved it is owned by everyone and everyone is obligated to fully commit to it, you prevent the sociopaths within your ranks from weaseling out and throw anyone under the bus. You eliminate the motivation to steer people in your team down a bad path to afterwards portray yourself as the only sane, competent guy in the ranks, because you have to explicitly sign off on the project. Once you sign off on the project, any extraordinary miraculous epiphany that happens after the fact is something that you must be held liable for, because it becomes obvious that you were never acting on behalf of the team's best interests. Therefore this sociopath move is no longer something that benefits you, and so the perverse incentives to screw over your team members is no longer there.

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.
        2y ago