5 ms·

Being politically correct vs getting the job done, I'll always choose getting the job done. There is plenty or role playing projects where your feeling matter m

Being politically correct vs getting the job done, I'll always choose getting the job done. There is plenty or role playing projects where your feeling matter more than your skills. In last couple of jobs I am always asking about company policy, if they start piling about diversity and getting everybody heard and how everybody's feelings are most important thing, I don't want to work there. Earn your place with your quality and your skills, not with the help of inventing newer and newer rules until nobody can say how crappy, sub average and difficult to work with you are. (Talking to a random programmer with no skills but huge area of possible butt-hurt). Edit: btw can't agree more with Stallman if that's not clear from my post. Love that guy.

SolaceQuantum 8y ago
> Being politically correct vs getting the job done, I'll always choose getting the job done. I am absolutely baffled at the idea that there is ever a situation where getting the job done requires a choice to be politically incorrect as implied here. Do you have an example of the phenomenon you're discussing?
- mirko22 8y ago
  For example not calling a problem in the code “a problem” but “possible place for improvement” as to do so might lead people to think their code is “problematic”... then i resigned...
  - SolaceQuantum 8y ago
    I’m unsure if this is the sort of politics that’s the context of the article in question. For clarity, the article in question spawned off of an email thread regarding calling women by nicknames in a condescending manner without their consent.
    - dec0dedab0de 8y ago
      I am absolutely baffled at the idea that there is ever a situation where... {example} I’m unsure if this is the sort of politics that’s the context of the article... I think it's fair to assume they were replying to you, not the article.
      - SolaceQuantum 8y ago
        Yes, within context of the article, and the ambiguous language of the poster, I'm questioning an example in which politics in context of the article applies to the experiences of the claim in question. The claim in question then refers to an example which does not apply to the context of the article. I remain fairly confused.
        binaryapparatus 8y ago
        Let me explain further then. It is all tied in, across the spectrum, along with linux code of conduct and sqlite topic today. In 'normal' company I can either respect the rules or walk away, there is usually little room for changing them. In open source project, small number of vocal butt hurts or political opponents that can use and channel 'hurt ones' can do much harm to the project, because they 'can' enforce different rules by being very noisy. In this particular case, same with Linux CoC, reasons to try to apply or change rules can have much more sinister motives than what it seems on the surface. Case in point. 1. Initial linux CoC is introduced by Greg KH, after one sensitive 'programmer' got hurt by Linus general behavior. Oh also she was working closely with Greg if I am not mistaken. https://lkml.org/lkml/2013/7/15/374 https://lkml.org/lkml/2013/7/15/374 2. Next Linux leaves the project (temporarily? fingers crossed) and Greg KH remains to be the top decision maker for what goes in into kernel. Same guy who wanted to push d-bus like his life depends on it, which doesn't show good judgment for the project well being. 3. Then one of the first things to do is to introduce even more rules, even if Linus returns soon: https://lkml.org/lkml/2018/10/22/188 https://lkml.org/lkml/2018/10/22/188 So underhand politics that has nothing to do with small tiny sensitive souls continues and quickly. When I see Stallman not buying CoC crap I respect that. Did I explain better?
        8y ago
- binaryapparatus 8y ago
  Yeah, like mirko said, being pressured by project leader to merge absolute crap (I was in charge of merging), "because it works and we don't want to suppress less skilled colleagues". "Try to explain nicely how to do it better" while that other guy a) doesn't want to learn and b) has feelings that are more important that making better software / learning. Edit: to clarify, that other guy couldn't understand the project or how to do proper code so all the PC dance afterwards is the perfect shield and role playing. I just walked away after few weeks.
  - ryanobjc 8y ago
    that's not political correctness, that's just good old fashioned office politics.
  - jl6 8y ago
    Hey, I don’t know your situation so this may be nonsense, but what you describe doesn’t sound so PC. The guy’s code worked? Doesn’t sound unreasonable that the project leader would want it merged. Put the technical debt on the backlog, get on with writing other code that works. The project leader presumably had a team to manage. Seems perfectly understandable that they would want all their team contributing, even if some team members were vastly more productive than others. The alternative is over-reliance on key personnel, or back to the recruitment treadmill (both of these are risks and uncertainties - which it’s the PM’s job to manage down). The project leader should want his less skilled employees to grow their skills so that he may one day have a greater breadth and depth of talent at his disposal. It might even be reasonable for the leader to want his most talented developers to do nothing but coach junior colleagues - particularly on a typical project that isn’t rocket science, where 5 average developers will be more useful than one rockstar. Like I said, I don’t know your situation. My point is that the behaviour you describe seems like it could be quite normal and rational and not motivated by PCness at all.
    - jf- 8y ago
      I have to agree. We tread a fine line here between being honest and being assholes. Let’s try to stay on the right side of that line.
- prepend 8y ago
  I have a lot of examples :) I once felt the same way, that there’s always a good way to give criticism. The shit sandwich really works well in even the mist dire situations (“this is great,” “this is garbage,” “but this is great too”). But I once had a co-worker who had an opposing development philosophy. It was in a bit of a weird, anarchic environment where there was little supervision, but steady budgets. There was an algorithm made and after reviewing it, it was just really, really bad. It was for improving health, but it used the wrong population, it inferred from data inappropriately, it made broad recommendations, and it did so I consistently. It was garbage, but it’s not helpful to say that as that never really helps and is not constructive and not accurate. Basically what you’re saying. I got the merge request and sent it back with a thoughtful commentary, adding in another peer for input, asking for test cases, asking for user story requests, etc. Pretty polite. They resubmitted it unchanged saying “no, I know it’s right. Just take it and we’ll fix it later.” (There’s no we, it’s just this one person). I spent more time and sent more detail, showing similar, valid changes. Same thing back. I spent probably a few hours between the two responses and they were resubmitted within seconds. I figured I’d chat with the person so based on work schedules sent an invite for two days away. Person said they couldn’t wait, had to go now. I tagged the other two maintainers, one was on the initial reply, and asked for a review. They pointed to response #1 and said “no, refer to reasons.” Submitted then went to boss land and asked boss to approve the merge. Boss can’t do that, etc etc. Boss and I meet with submitter. Submitter asks us to read original submission and gives nothing further. Boss asks me to reconsider, I point out comments for improvements, submitter says they won’t change them. So request stays at no. Lots of HR madness takes place over the next few weeks. Merge request never made it. I probably spent 40 hours, plus peers and submitter added on. Obviously, I’m not skilled enough to communicate why the merge request wasn’t sufficient. I’d love to learn, and am always trying. But I sometimes wonder that I could have saved a lot of time by just saying “this request is a garbage fire and a waste of time to discuss further. You are unworthy.” It wouldn’t have worked to make the submission good, but would have cut directly to HR and skilled all the well intentioned attempts that ate up time. If this were OSS, it might be good for the community to prevent future stupid stuff. I’m not sure what the solution is as you have folks who are good in one thing (algorithm design), but bad in another thing (conflict resolution / mentoring randos). Hopefully you’re lucky and have leads with both skills.
s73v3r_ 8y ago
"Being politically correct vs getting the job done, I'll always choose getting the job done." False choice; there is absolutely no reason whatsoever that one would ever need to choose between being polite to others and getting the job done.
- binaryapparatus 8y ago
  Oh there is third option too. See my other post, I walked away while precious little programmer that has no skills but has feelings remained working at that company. > False choice; there is absolutely no reason whatsoever that one would ever need to choose between being polite to others and getting the job done. Sounds great but in reality not always possible.
- deleted 8y ago
  [deleted]
mwfunk 8y ago
All of this stuff is in service of getting the job done. If people can't usefully collaborate with other people because they literally never developed adult social skills (not uncommon in the tech world), then they're not going to be good contributors or collaborators. They won't know how to constructively criticize others, or take constructive criticism, they won't learn from their mistakes, and they might not even learn the right lessons from others' mistakes. The organization as a whole suffers, which is a lot worse than any individual not getting what they want.
- binaryapparatus 8y ago
  What are the priorities? Is 'collaborating' supreme goal on its own? a) Quality b) Feelings c) Having as many as possible people 'collaborating' d) Getting job done Pick two. They are not excluding others but I wonder what the priorities are. I pick A and D, C is welcome but not priority, B only if it doesn't clash with any of other goals.
  - mwfunk 8y ago
    I agree with that list of priorities, but I don't know what you mean by "feelings"- I wouldn't use that word in my own division of goals. I would just call it "effective communication", not "feelings". You're phrasing it as if the the scenario people are trying to avoid is some brutally honest truthteller vs. some hypersensitive weenie who can't handle the truth, and that people are claiming that it's more important, in that situation, to preserve the weenie's feelings than it is for truth to be expressed. That's not the intention of CoC's or workplace etiquette or professionalism. Think of that truthteller vs. weenie scenario: in cases where one person is potentially hurting someone else's feefees over professional criticism, there is for sure some subset of those cases where that's exactly what's happening. One person is 100% correct, and is being brutally honest with someone else who is both incompetent and hypersensitive, and deserves that brutally honest criticism because that's the only way to get through to them. That's a subset of those situations. I don't know how much of a subset- 25%? 50%? My gut says more like 1-5%, but my gut is naturally biased (like everyone's). But in 100% of those situations, I guarantee that the brutally honest truthteller THINKS that's what the situation is. In my experience, the brutally honest truthteller is expressing their own confidence in themselves far more often than they're expressing an objective measure of cold hard truth. Some subset of them are expressing cold hard truth that can't be ignored, but all of them think they are. If they had really truly done their homework and knew what they were talking about, they would have eventually learned humility and skepticism, and would be much less likely to jump into the brutally honest truthteller role in the first place. Simple example of productive etiquette: when criticizing someone's work, it's generally much more effective to phrase it in such a way that it doesn't come off like a personal attack. Meaning, some variant of "this code is bad" works better than some variant of "your code is bad". In the latter case, natural and common cognitive biases (i.e., human nature) are such that people will almost always feel at least a little bit defensive, and are more likely to reject the rational aspects of the criticism because they sense that the other person is criticizing their work for personal rather than rational reasons. I'm totally aware of these biases in myself and I'm still almost as susceptible to them as anyone. It makes it easy to brush off the criticism as coming from an irrational place, on a subconscious level that never even rises into the conscious mind. Making it personal diminishes the credibility of the criticizer in the eyes of the criticized. So, as a rule, I have found that it's much more effective to make an effort to phrase things as objective criticisms rather than personal attacks. This isn't tiptoeing around someone's feefees, it's literally just making an effort to communicate in a way that is most likely to produce a positive outcome (in terms of production, not feefees- the preserved feefees are just a pleasant side effect). In my experience, that's all that most CoC's or calls for workplace civility or whatever are advocating. Some people are used to working in large organizations full of big egos and unbalanced people from all over the world. Other people have spent their professional lives in much smaller bubbles, and never had cause to think about any of this stuff. But successful open source projects resemble the former much more than the latter, and can require similar social awareness to keep things running smoothly. Things like CoC's, ideally, just make sure that everyone's on the same page in as harmless and nonintrusive way as possible. I'm sure they've been misused or poorly implemented in specific situations, but in principle it all seems eminently reasonable to me.

SolaceQuantum 8y ago

> Being politically correct vs getting the job done, I'll always choose getting the job done. I am absolutely baffled at the idea that there is ever a situation where getting the job done requires a choice to be politically incorrect as implied here. Do you have an example of the phenomenon you're discussing?

mirko22 8y ago
For example not calling a problem in the code “a problem” but “possible place for improvement” as to do so might lead people to think their code is “problematic”... then i resigned...
- SolaceQuantum 8y ago
  I’m unsure if this is the sort of politics that’s the context of the article in question. For clarity, the article in question spawned off of an email thread regarding calling women by nicknames in a condescending manner without their consent.
  - dec0dedab0de 8y ago
    I am absolutely baffled at the idea that there is ever a situation where... {example} I’m unsure if this is the sort of politics that’s the context of the article... I think it's fair to assume they were replying to you, not the article.
    - SolaceQuantum 8y ago
      Yes, within context of the article, and the ambiguous language of the poster, I'm questioning an example in which politics in context of the article applies to the experiences of the claim in question. The claim in question then refers to an example which does not apply to the context of the article. I remain fairly confused.
      - binaryapparatus 8y ago
        Let me explain further then. It is all tied in, across the spectrum, along with linux code of conduct and sqlite topic today. In 'normal' company I can either respect the rules or walk away, there is usually little room for changing them. In open source project, small number of vocal butt hurts or political opponents that can use and channel 'hurt ones' can do much harm to the project, because they 'can' enforce different rules by being very noisy. In this particular case, same with Linux CoC, reasons to try to apply or change rules can have much more sinister motives than what it seems on the surface. Case in point. 1. Initial linux CoC is introduced by Greg KH, after one sensitive 'programmer' got hurt by Linus general behavior. Oh also she was working closely with Greg if I am not mistaken. https://lkml.org/lkml/2013/7/15/374 https://lkml.org/lkml/2013/7/15/374 2. Next Linux leaves the project (temporarily? fingers crossed) and Greg KH remains to be the top decision maker for what goes in into kernel. Same guy who wanted to push d-bus like his life depends on it, which doesn't show good judgment for the project well being. 3. Then one of the first things to do is to introduce even more rules, even if Linus returns soon: https://lkml.org/lkml/2018/10/22/188 https://lkml.org/lkml/2018/10/22/188 So underhand politics that has nothing to do with small tiny sensitive souls continues and quickly. When I see Stallman not buying CoC crap I respect that. Did I explain better?
        8y ago
binaryapparatus 8y ago
Yeah, like mirko said, being pressured by project leader to merge absolute crap (I was in charge of merging), "because it works and we don't want to suppress less skilled colleagues". "Try to explain nicely how to do it better" while that other guy a) doesn't want to learn and b) has feelings that are more important that making better software / learning. Edit: to clarify, that other guy couldn't understand the project or how to do proper code so all the PC dance afterwards is the perfect shield and role playing. I just walked away after few weeks.
- ryanobjc 8y ago
  that's not political correctness, that's just good old fashioned office politics.
- jl6 8y ago
  Hey, I don’t know your situation so this may be nonsense, but what you describe doesn’t sound so PC. The guy’s code worked? Doesn’t sound unreasonable that the project leader would want it merged. Put the technical debt on the backlog, get on with writing other code that works. The project leader presumably had a team to manage. Seems perfectly understandable that they would want all their team contributing, even if some team members were vastly more productive than others. The alternative is over-reliance on key personnel, or back to the recruitment treadmill (both of these are risks and uncertainties - which it’s the PM’s job to manage down). The project leader should want his less skilled employees to grow their skills so that he may one day have a greater breadth and depth of talent at his disposal. It might even be reasonable for the leader to want his most talented developers to do nothing but coach junior colleagues - particularly on a typical project that isn’t rocket science, where 5 average developers will be more useful than one rockstar. Like I said, I don’t know your situation. My point is that the behaviour you describe seems like it could be quite normal and rational and not motivated by PCness at all.
  - jf- 8y ago
    I have to agree. We tread a fine line here between being honest and being assholes. Let’s try to stay on the right side of that line.
prepend 8y ago
I have a lot of examples :) I once felt the same way, that there’s always a good way to give criticism. The shit sandwich really works well in even the mist dire situations (“this is great,” “this is garbage,” “but this is great too”). But I once had a co-worker who had an opposing development philosophy. It was in a bit of a weird, anarchic environment where there was little supervision, but steady budgets. There was an algorithm made and after reviewing it, it was just really, really bad. It was for improving health, but it used the wrong population, it inferred from data inappropriately, it made broad recommendations, and it did so I consistently. It was garbage, but it’s not helpful to say that as that never really helps and is not constructive and not accurate. Basically what you’re saying. I got the merge request and sent it back with a thoughtful commentary, adding in another peer for input, asking for test cases, asking for user story requests, etc. Pretty polite. They resubmitted it unchanged saying “no, I know it’s right. Just take it and we’ll fix it later.” (There’s no we, it’s just this one person). I spent more time and sent more detail, showing similar, valid changes. Same thing back. I spent probably a few hours between the two responses and they were resubmitted within seconds. I figured I’d chat with the person so based on work schedules sent an invite for two days away. Person said they couldn’t wait, had to go now. I tagged the other two maintainers, one was on the initial reply, and asked for a review. They pointed to response #1 and said “no, refer to reasons.” Submitted then went to boss land and asked boss to approve the merge. Boss can’t do that, etc etc. Boss and I meet with submitter. Submitter asks us to read original submission and gives nothing further. Boss asks me to reconsider, I point out comments for improvements, submitter says they won’t change them. So request stays at no. Lots of HR madness takes place over the next few weeks. Merge request never made it. I probably spent 40 hours, plus peers and submitter added on. Obviously, I’m not skilled enough to communicate why the merge request wasn’t sufficient. I’d love to learn, and am always trying. But I sometimes wonder that I could have saved a lot of time by just saying “this request is a garbage fire and a waste of time to discuss further. You are unworthy.” It wouldn’t have worked to make the submission good, but would have cut directly to HR and skilled all the well intentioned attempts that ate up time. If this were OSS, it might be good for the community to prevent future stupid stuff. I’m not sure what the solution is as you have folks who are good in one thing (algorithm design), but bad in another thing (conflict resolution / mentoring randos). Hopefully you’re lucky and have leads with both skills.

s73v3r_ 8y ago

"Being politically correct vs getting the job done, I'll always choose getting the job done." False choice; there is absolutely no reason whatsoever that one would ever need to choose between being polite to others and getting the job done.

binaryapparatus 8y ago
Oh there is third option too. See my other post, I walked away while precious little programmer that has no skills but has feelings remained working at that company. > False choice; there is absolutely no reason whatsoever that one would ever need to choose between being polite to others and getting the job done. Sounds great but in reality not always possible.
deleted 8y ago
[deleted]

mwfunk 8y ago

All of this stuff is in service of getting the job done. If people can't usefully collaborate with other people because they literally never developed adult social skills (not uncommon in the tech world), then they're not going to be good contributors or collaborators. They won't know how to constructively criticize others, or take constructive criticism, they won't learn from their mistakes, and they might not even learn the right lessons from others' mistakes. The organization as a whole suffers, which is a lot worse than any individual not getting what they want.

binaryapparatus 8y ago
What are the priorities? Is 'collaborating' supreme goal on its own? a) Quality b) Feelings c) Having as many as possible people 'collaborating' d) Getting job done Pick two. They are not excluding others but I wonder what the priorities are. I pick A and D, C is welcome but not priority, B only if it doesn't clash with any of other goals.
- mwfunk 8y ago
  I agree with that list of priorities, but I don't know what you mean by "feelings"- I wouldn't use that word in my own division of goals. I would just call it "effective communication", not "feelings". You're phrasing it as if the the scenario people are trying to avoid is some brutally honest truthteller vs. some hypersensitive weenie who can't handle the truth, and that people are claiming that it's more important, in that situation, to preserve the weenie's feelings than it is for truth to be expressed. That's not the intention of CoC's or workplace etiquette or professionalism. Think of that truthteller vs. weenie scenario: in cases where one person is potentially hurting someone else's feefees over professional criticism, there is for sure some subset of those cases where that's exactly what's happening. One person is 100% correct, and is being brutally honest with someone else who is both incompetent and hypersensitive, and deserves that brutally honest criticism because that's the only way to get through to them. That's a subset of those situations. I don't know how much of a subset- 25%? 50%? My gut says more like 1-5%, but my gut is naturally biased (like everyone's). But in 100% of those situations, I guarantee that the brutally honest truthteller THINKS that's what the situation is. In my experience, the brutally honest truthteller is expressing their own confidence in themselves far more often than they're expressing an objective measure of cold hard truth. Some subset of them are expressing cold hard truth that can't be ignored, but all of them think they are. If they had really truly done their homework and knew what they were talking about, they would have eventually learned humility and skepticism, and would be much less likely to jump into the brutally honest truthteller role in the first place. Simple example of productive etiquette: when criticizing someone's work, it's generally much more effective to phrase it in such a way that it doesn't come off like a personal attack. Meaning, some variant of "this code is bad" works better than some variant of "your code is bad". In the latter case, natural and common cognitive biases (i.e., human nature) are such that people will almost always feel at least a little bit defensive, and are more likely to reject the rational aspects of the criticism because they sense that the other person is criticizing their work for personal rather than rational reasons. I'm totally aware of these biases in myself and I'm still almost as susceptible to them as anyone. It makes it easy to brush off the criticism as coming from an irrational place, on a subconscious level that never even rises into the conscious mind. Making it personal diminishes the credibility of the criticizer in the eyes of the criticized. So, as a rule, I have found that it's much more effective to make an effort to phrase things as objective criticisms rather than personal attacks. This isn't tiptoeing around someone's feefees, it's literally just making an effort to communicate in a way that is most likely to produce a positive outcome (in terms of production, not feefees- the preserved feefees are just a pleasant side effect). In my experience, that's all that most CoC's or calls for workplace civility or whatever are advocating. Some people are used to working in large organizations full of big egos and unbalanced people from all over the world. Other people have spent their professional lives in much smaller bubbles, and never had cause to think about any of this stuff. But successful open source projects resemble the former much more than the latter, and can require similar social awareness to keep things running smoothly. Things like CoC's, ideally, just make sure that everyone's on the same page in as harmless and nonintrusive way as possible. I'm sure they've been misused or poorly implemented in specific situations, but in principle it all seems eminently reasonable to me.