5 ms·

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 le

by 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".
  - KronisLV 4y ago
    Hah, that's a fair point. Whenever someone tries to figure out how to store files, I'm usually inclined to just point them in the direction of S3 to attempt to at least minimize some of the eventual issues of dealing with files. 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).
    - larve 4y ago
      Once you involve the cloud, things get exponentially more complicated. Your `fwrite(foobar)` has ramifications that no human can legitimately understand. 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.

by larve 4y ago

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".
- KronisLV 4y ago
  Hah, that's a fair point. Whenever someone tries to figure out how to store files, I'm usually inclined to just point them in the direction of S3 to attempt to at least minimize some of the eventual issues of dealing with files. 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).
  - larve 4y ago
    Once you involve the cloud, things get exponentially more complicated. Your `fwrite(foobar)` has ramifications that no human can legitimately understand. 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.