3 ms·

Let me stretch your analogy to make the opposite point: I am employed as an embedded developer. The position I was hired for has a heavy focus on C programming

Let me stretch your analogy to make the opposite point: I am employed as an embedded developer. The position I was hired for has a heavy focus on C programming. I would never write the "C is stupid and nobody should use it anymore" articles, but I do still think they have merit and will share them around the company. As someone who knows how to read an argument and separate wheat from the chaff, I have been experimenting with Rust and raising the possibility of adoption in certain areas of new development. I do not intend to write C at this job. I intend to leverage the right tools to achieve our embedded goals. For as long as that means C, it'll be C, but C might not be the most appropriate tool and I am open to changing our tools.

fixermark 9y ago
Really, the language- or framework-based examples don't apply well because people aren't tools. CoCs generally protect people from bad behavior by other people, under the assumption that debating the merits of people the way you'd debate the merits of tools is, well, a dick move.
- scubapilot 9y ago
  I agree, people are not tools. But codes of conduct are tools. They are used by people, to achieve goals.
geofft 9y ago
Yes, and I think that's fine. (I'm in a largely similar position in my own job as it happens, and my management agrees: we probably want out of the technology I'm working on, but we want it well-maintained until we figure out what our better option is.) My sense, and again I am an outsider and might be wrong, is that Rod wasn't of the opinion that he'll enforce the CoC as long as the TSC (other smart people) and the Node community see it as the right current plan, but he'll advocate for long-term change. He was of the opinion that, right now, not only was the CoC without merit, but it's reasonable for him to actively apologize for moderation actions that the rest of the TSC took. That is I think not directly analogous to what you are doing. It is much more analogous to you replying to your coworkers code reviews with "-1, it's 2017, you shouldn't write in C," or replying to your customers' bug reports with "Yeah, well, we're writing in C so of course our code is broken." Your coworkers are willing to work with you because they believe, regardless of what articles you're sharing, that for the foreseeable future you will write the best C you can and help them write the best C they can. If that trust is there, advocating for change is totally reasonable. If it's not, and either you believe that your coworkers are hopelessly misguided or they believe that you're hopelessly misguided, one of the two factions needs to leave for the team to be productive again.

fixermark 9y ago

Really, the language- or framework-based examples don't apply well because people aren't tools. CoCs generally protect people from bad behavior by other people, under the assumption that debating the merits of people the way you'd debate the merits of tools is, well, a dick move.

scubapilot 9y ago
I agree, people are not tools. But codes of conduct are tools. They are used by people, to achieve goals.

geofft 9y ago

Yes, and I think that's fine. (I'm in a largely similar position in my own job as it happens, and my management agrees: we probably want out of the technology I'm working on, but we want it well-maintained until we figure out what our better option is.) My sense, and again I am an outsider and might be wrong, is that Rod wasn't of the opinion that he'll enforce the CoC as long as the TSC (other smart people) and the Node community see it as the right current plan, but he'll advocate for long-term change. He was of the opinion that, right now, not only was the CoC without merit, but it's reasonable for him to actively apologize for moderation actions that the rest of the TSC took. That is I think not directly analogous to what you are doing. It is much more analogous to you replying to your coworkers code reviews with "-1, it's 2017, you shouldn't write in C," or replying to your customers' bug reports with "Yeah, well, we're writing in C so of course our code is broken." Your coworkers are willing to work with you because they believe, regardless of what articles you're sharing, that for the foreseeable future you will write the best C you can and help them write the best C they can. If that trust is there, advocating for change is totally reasonable. If it's not, and either you believe that your coworkers are hopelessly misguided or they believe that you're hopelessly misguided, one of the two factions needs to leave for the team to be productive again.