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.
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.
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.
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.
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.
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
> 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.
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".
You know, even MongoDB GridFS or binary blobs in RDBMSes could be less problematic options, rather than dealing with inodes, maximum file path lengths, file name constraints, storing metadata, maximum files in a directory and eventually having to build a system for having a tree of nested folders to work around those (a bit like what Ruby on Rails ActiveStorage does with uploaded files out of the box, for example).
That's what I meant with . I am happy to write `fwrite(foobar)` and get the project going, but it's not simple, and there might be very valid reasons to not do just `fwrite(foobar)`. If you don't want me to even mention these, then I'm out.
Otherwise, I will fully engage. I'm really a pragmatist when it comes to getting stuff done. Anything getting shipped is better than nothing getting shipped, and I will maintain it for as long as it needs to.
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.