« first day (6 days earlier)    last day (15 days later) » 

3:38 PM
@jpmc26 There's a real tension here, though, between what's painful for the listener, and what's painful for the speaker. Clearly it's true that people sometimes need to hear that they are attacking a programming problem incorrectly. People also sometimes need to hear that they are communicating their feedback badly. So all of this reasoning applies in both directions.
Perhaps it's true that the CoC now attributes too much blame to the speaker; I'm not sure. But the truth is that sometimes that's where it belongs, even if you assume good intentions. Also, sometimes neither party is to blame, and sometimes both parties are to blame. In any case, it obviously behooves advice-givers to accept advice about their advice-giving in the same professional terms as they are expecting their advice to be received.
So the CoC should be worded in a way that demonstrates that these expectations of professionalism are to be applied equitably to both parties. It's not fair or accurate to assume that people experienced in programming are automatically giving advice in good ways, or to hold them to different expectations merely because they are experts in one particular area.
I gather that you are also seeing a middle path here, but based on everything you've said, I can't help but think that you're prioritizing the right of the expert coder to deliver criticism (about code) over the right of the novice coder to deliver criticism (about things other than code).
 
4:04 PM
@senderle It's not so much that the novice can't deliver criticism. It's that Jon's criticism is invalid. The comments in his article are demonstrably objective and well intentioned. They are certainly professional. But instead of acknowledging this and accepting the responsibility for dealing with his feelings on the matter, Jon seeks to blame them for how he feels. I think the reality is that Jon was having a hard time admitting his approach in that question was wrong.
Furthermore, the advice he calls "patronizing" is standard advice for the typical situation. Without having covered a good reason why that advice wouldn't apply in his question, there's no reason for someone to refrain from giving it or even just re-emphasizing the dangers that make it good advice. It's usually to your benefit for people to dissuade you from doing something that's likely to cause problems. There isn't anything inherently unprofessional or rude about it.
I have a major problem with basing a complete revamp of policy on a criticism that's invalid to begin with.
 
 
2 hours later…
6:25 PM
@jpmc26 You say "there isn't anything inherently unprofessional or rude about it." I agree. But context matters. Lots of things that aren't inherently unprofessional or rude can be unprofessional or rude in a particular context. That appears to be Jon's argument in this case. You might disagree, but you aren't addressing context at all in support of your claim that his criticism is invalid.
Your argument appears to me to be that comments that are "demonstrably objective and well intentioned" can't be inappropriate. I don't think that's true in general.
 
6:45 PM
@senderle On the contrary, I've used the context to defend their professionalism. Namely that Jon's post did not (and still does not) provide a compelling reason why the standard tools for his goals are insufficient or why the very large risks the comments point out are acceptable. If those had been in the question and they were ignored, maybe Jon would have a point, but they aren't.
What Jon did in that post is examine his internal feelings and insisting that there must be an external explanation for them. That is not something you can assume. You must also examine internal causes. He then conjures something out of the comments that doesn't exist because of that assumption.
Doing that is in and of itself rude and unwelcoming, and indeed it's rather hypocritical if Jon is arguing we should be more careful in our responses.
I don't think Jon is trying to be nefarious here, but he seems to have bought into a worldview that insists the blame must rest on the respondents rather than accept that his feelings can arise despite the respondents doing everything they should have. I get the temptation to look outside for the cause of your problems; I have to stave it off all the time and find myself constantly having to accept that I was wrong in some way. But we have to fight that urge it because it isn't true.
I do agree that what we really want is more of a middle path, but my goal here is to counter SO employees moving too far in one particular direction. I can't really solve that problem by putting more emphasis on the other extreme. And I think actually that our old standard was a very good stance. It sought just to handle rudeness where it existed instead of insisting on placing all the responsibility on respondents.
@senderle I think that is much closer to true than it is to false (because "demonstrably objective and well intentioned" responses being inappropriate is rare), but more importantly, this isn't really what I'm saying. I'm specifically looking at Jon's approach to his feelings and his specific example, and what I'm seeing amounts to the denial that the asker has any responsibility to deal with their own feelings. He demands that every response should be perfectly worded to make them feel good.
I don't think I'm strawmanning Jon to a more extreme position, either. In the two comments he cited, I see nothing but a professional warning of danger and an attempt to help him realize the standard tools do what he wants. Yet he asserts these are "patronizing," even though he gave no reason to believe he knew any of what they said. That is an absurdly high standard. There is no meaningful difference between a standard that high and the extreme position I'm assign to him.
The second one could have been slightly better, but if you stop and assume good intentions, it is pretty clearly just trying to help the asker understand. The first really couldn't have been improved at all; it's completely neutral and factual. The context only reinforces their neutrality, since the question didn't and doesn't address any of the content in the comments. Saying those two specific ones are inappropriate is evidence of an inherently extreme position.
I hope that clarifies what I'm saying and why.
 
7:23 PM
@jpmc26 I think I understand what you're saying pretty clearly, and I see pretty clearly where we disagree. viz...
@jpmc26 I don't think this is an absurdly high standard. It's just a matter of the assumptions you bring to a conversation. The wording flows naturally from those assumptions. So I think we disagree about the assumptions commenters should bring to these conversations.
 
8:04 PM
@senderle You think that labeling a comment that points out that your intended approach will cause disk filling and security breaches as "condescending" is not an absurdly high standard?
How about this? Tell me how you think the first comment should have been written.
 
8:24 PM
@jpmc26 Well first of all, I just don't think this is necessarily true: "you'd have... several MB of logs for every request." That totally depends on context. I mean -- a short script with no loops? No way. The potential for security issues is clearer, but even that's not necessarily true. And the question indicates the asker probably knows some of the potential ramifications; they've done this with bash scripts already. A polite comment would have acknowledged some of this.
 
@senderle I rather strongly disagree. When someone is asking to do something that's very high risk and is almost never the right approach anyway, you don't waste words watering down your statement about the level of risk involved. That carries too much risk of not correctly communicating the severity of the problem. On top of all this is all the problems I mentioned before about time and space constraints.
Ruby is not bash. bash needs a feature like that because of the way its string expansion works; you need to see the full string sometimes to see what it actually resolved to. Ruby isn't like that; it has a clear delineation between code and values and doesn't mix them the way bash does. So an equivalent of xtrace isn't required. It would take several comments to cover all that. Choosing to refrain in no way makes the comment impolite.
And delving into that would be telling Jon even more that he's working in the wrong mindset, likely making him feel even worse.
 
 
2 hours later…
10:10 PM
@jpmc26 We seem to be talking at cross purposes. I never suggested that the commenter should go into more technical detail about why this is a bad idea. Let's just agree to disagree.
 

« first day (6 days earlier)    last day (15 days later) »