5 ms·

> I think people can mean either one by "giving in", I am wondering whether the OP, in rejecting "pretending I agree when I don't" is accidentally being the per

> I think people can mean either one by "giving in", I am wondering whether the OP, in rejecting "pretending I agree when I don't" is accidentally being the person who "always insists on getting their way every time". Yes, it's possible that the OP is accidentally being a bully by insisting on getting their way every time. But it's also possible that everything the OP is saying is true, and the other party really is objectively wrong. Do you agree it's possible the OP is right? I personally have encountered a situation where a tech lead repeatedly doubled down on idea that was objectively deeply flawed, but they had a lot of political capital, so management told me I just needed to "give in". Other engineers agreed with my assessment in private, but weren't willing to say so publicly.

KronisLV 4y ago
> I personally have encountered a situation where a tech lead repeatedly doubled down on idea that was objectively deeply flawed, but they had a lot of political capital, so management told me I just needed to "give in". Other engineers agreed with my assessment in private, but weren't willing to say so publicly. That that point you need to choose, which you value more highly: correctness and finding the best technical solution, or maintaining as much team cohesion and not "stirring the water" too much. So, if it's not your head on the chopping block, but a public decision about how to do things (ideally documented in an ADR - architecture decision record, with an author attached), just roll with it and indeed "give in". Ideally with some of your concerns documented, as well as a few prepared suggestions for how to deal with the eventual fallout and how to fix some of the things that might go wrong.
- larve 4y ago
  ADRs / RFCs are great. Compromise is a necessity for anything where there is no right or wrong answer, only unknoowns with more or less certainty and more or less strongly held opinions. Getting everybody's opinion and insight into a question, documenting it, searching for the best way forward, and then reaching and documenting a compromise, that to me is good engineering. I fully support building things in a way that I didn't suggest, that's what the team agreed on and gets the project going. That's not what my point was about, however. I am not going to state "python is better than C++" just because someone wants me to say it, or back down from something I know is a fact, like "writing a file to disk is a complicated process." And I'm ready to quit over that.
  - KronisLV 4y ago
    > I am not going to state "python is better than C++" just because someone wants me to say it... You shouldn't, quite the opposite - you should be able to express your concerns freely or at least make them known in whatever form of a "paper trail" is available. Better yet, if you are able to provide examples of what might go wrong with a particular technical choice and how to address it. > ...or back down from something I know is a fact, like "writing a file to disk is a complicated process." This is where things get a bit more complicated, though. If you disagree with an approach that the team or certain members might pick, to the point where it blocks progress and they're not intent on budging their own views either, then clearly work cannot continue. In those situations, there are just a few ways how things might go: - neither you, nor them concede, work cannot continue until an external intervention - one of you concedes, work continues, good decisions are made and there are no problems down the road - one of you concedes, work continues, bad decisions are made and there are problems down the road So the only option for work to get done, is for one of the people to give in. Since sometimes you cannot always control difficult people yourself (with the resources available to you), it feels to me that giving in to sub-optimal choices is the only option in those cases, short of quitting. > And I'm ready to quit over that. This is also a valid choice, though it also probably reflects how hot the job market is in your country, how important having a job is at the present moment, as well as your tolerance or emotional involvement in the project. Some might jump around various companies until they may or may not find the environment that they're looking for, others might have to temporarily tolerate some bad engineering until another project comes along, others end up feeling miserable when the culture is all bad. I guess it varies quite a bit.
    - larve 4y ago
      On the topic of filesystems: for me, hardware storage systems, file systems, operating systems, user library, filesystem caching, file formats, persistence guarantees, recovery, that stuff is really complicated. I just can't say that it's simple, because to me it never will be. Maybe it's simple for the other person, but I don't understand why "giving in" helps any of us in this case. I just won't say "writing a file is simple", even if you threaten to fire me. That's fine by me, I might change my mind if my survival depends on it, but it really is not what I'm here for. We can go ahead writing your file-based persistence layer, and I"m fine supporting and maintaining it too. But I won't say that "it's simple".
- a_puppy 4y ago
  > or maintaining as much team cohesion and not "stirring the water" too much. On an individual level, yes, that's the choice I had. But on an organizational level, it's possible to do much better! In a healthy organization, tech leads listen to feedback and evaluate it with an open mind, and are willing to acknowledge that they're wrong. If they don't do that, then a healthy organization removes them from their position. In my case, this particular tech lead had a long history of being toxic, but the manager refused to fix the problem; this was a case of organizational dysfunction. I don't know the details of the OP's situation, but I think it's possible they're running into something similar: Their coworkers aren't listening to valid points, and management isn't holding them accountable for being open-minded. If the org considers this behavior normal, I'd consider that a form of org dysfunction.
jrochkind1 4y ago
> Yes, it's possible that the OP is accidentally being a bully by insisting on getting their way every time. But it's also possible that everything the OP is saying is true, and the other party really is objectively wrong. My point is that both of these things can be true. By insisting you always get your way in any dispute, you can be a bully even if you are always "objectively right". How do we know who is "objectively right"? Both sides believe they are, right? Have you never realized later you were wrong about something? > I personally have encountered a situation where a tech lead repeatedly doubled down on idea that was objectively deeply flawed, but they had a lot of political capital, so management told me I just needed to "give in". Other engineers agreed with my assessment in private, but weren't willing to say so publicly. I will say again that I am not suggesting that anyone lie about what they think, or say one thing publicly or another privately, or not share their true assessments publicly, or that this is a good culture where people think they need to.
- a_puppy 4y ago
  > How do we know who is "objectively right"? I don't think we have enough information about OP's situation to say for sure. I agree that many disputes are highly subjective, and there's no way to say who's objectively right. But I also think there are cases where, after listening and understanding both sides, it's pretty clear which side has a better argument. Objective reality does exist! People are sometimes bad at judging what's objective, especially when emotions run high; but it's not impossible. And, if the question is important, then finding the objectively correct answer is better for the success of the project.

KronisLV 4y ago

> I personally have encountered a situation where a tech lead repeatedly doubled down on idea that was objectively deeply flawed, but they had a lot of political capital, so management told me I just needed to "give in". Other engineers agreed with my assessment in private, but weren't willing to say so publicly. That that point you need to choose, which you value more highly: correctness and finding the best technical solution, or maintaining as much team cohesion and not "stirring the water" too much. So, if it's not your head on the chopping block, but a public decision about how to do things (ideally documented in an ADR - architecture decision record, with an author attached), just roll with it and indeed "give in". Ideally with some of your concerns documented, as well as a few prepared suggestions for how to deal with the eventual fallout and how to fix some of the things that might go wrong.

larve 4y ago
ADRs / RFCs are great. Compromise is a necessity for anything where there is no right or wrong answer, only unknoowns with more or less certainty and more or less strongly held opinions. Getting everybody's opinion and insight into a question, documenting it, searching for the best way forward, and then reaching and documenting a compromise, that to me is good engineering. I fully support building things in a way that I didn't suggest, that's what the team agreed on and gets the project going. That's not what my point was about, however. I am not going to state "python is better than C++" just because someone wants me to say it, or back down from something I know is a fact, like "writing a file to disk is a complicated process." And I'm ready to quit over that.
- KronisLV 4y ago
  > I am not going to state "python is better than C++" just because someone wants me to say it... You shouldn't, quite the opposite - you should be able to express your concerns freely or at least make them known in whatever form of a "paper trail" is available. Better yet, if you are able to provide examples of what might go wrong with a particular technical choice and how to address it. > ...or back down from something I know is a fact, like "writing a file to disk is a complicated process." This is where things get a bit more complicated, though. If you disagree with an approach that the team or certain members might pick, to the point where it blocks progress and they're not intent on budging their own views either, then clearly work cannot continue. In those situations, there are just a few ways how things might go: - neither you, nor them concede, work cannot continue until an external intervention - one of you concedes, work continues, good decisions are made and there are no problems down the road - one of you concedes, work continues, bad decisions are made and there are problems down the road So the only option for work to get done, is for one of the people to give in. Since sometimes you cannot always control difficult people yourself (with the resources available to you), it feels to me that giving in to sub-optimal choices is the only option in those cases, short of quitting. > And I'm ready to quit over that. This is also a valid choice, though it also probably reflects how hot the job market is in your country, how important having a job is at the present moment, as well as your tolerance or emotional involvement in the project. Some might jump around various companies until they may or may not find the environment that they're looking for, others might have to temporarily tolerate some bad engineering until another project comes along, others end up feeling miserable when the culture is all bad. I guess it varies quite a bit.
  - larve 4y ago
    On the topic of filesystems: for me, hardware storage systems, file systems, operating systems, user library, filesystem caching, file formats, persistence guarantees, recovery, that stuff is really complicated. I just can't say that it's simple, because to me it never will be. Maybe it's simple for the other person, but I don't understand why "giving in" helps any of us in this case. I just won't say "writing a file is simple", even if you threaten to fire me. That's fine by me, I might change my mind if my survival depends on it, but it really is not what I'm here for. We can go ahead writing your file-based persistence layer, and I"m fine supporting and maintaining it too. But I won't say that "it's simple".
a_puppy 4y ago
> or maintaining as much team cohesion and not "stirring the water" too much. On an individual level, yes, that's the choice I had. But on an organizational level, it's possible to do much better! In a healthy organization, tech leads listen to feedback and evaluate it with an open mind, and are willing to acknowledge that they're wrong. If they don't do that, then a healthy organization removes them from their position. In my case, this particular tech lead had a long history of being toxic, but the manager refused to fix the problem; this was a case of organizational dysfunction. I don't know the details of the OP's situation, but I think it's possible they're running into something similar: Their coworkers aren't listening to valid points, and management isn't holding them accountable for being open-minded. If the org considers this behavior normal, I'd consider that a form of org dysfunction.

jrochkind1 4y ago

> Yes, it's possible that the OP is accidentally being a bully by insisting on getting their way every time. But it's also possible that everything the OP is saying is true, and the other party really is objectively wrong. My point is that both of these things can be true. By insisting you always get your way in any dispute, you can be a bully even if you are always "objectively right". How do we know who is "objectively right"? Both sides believe they are, right? Have you never realized later you were wrong about something? > I personally have encountered a situation where a tech lead repeatedly doubled down on idea that was objectively deeply flawed, but they had a lot of political capital, so management told me I just needed to "give in". Other engineers agreed with my assessment in private, but weren't willing to say so publicly. I will say again that I am not suggesting that anyone lie about what they think, or say one thing publicly or another privately, or not share their true assessments publicly, or that this is a good culture where people think they need to.

a_puppy 4y ago
> How do we know who is "objectively right"? I don't think we have enough information about OP's situation to say for sure. I agree that many disputes are highly subjective, and there's no way to say who's objectively right. But I also think there are cases where, after listening and understanding both sides, it's pretty clear which side has a better argument. Objective reality does exist! People are sometimes bad at judging what's objective, especially when emotions run high; but it's not impossible. And, if the question is important, then finding the objectively correct answer is better for the success of the project.