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.
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.