4 ms·

Usually I try to resolve disagreements by asking questions. Either they end up poking holes in their own arguments or I learn where I made a mistake. Telling s

by jobu 10y ago

Usually I try to resolve disagreements by asking questions. Either they end up poking holes in their own arguments or I learn where I made a mistake. Telling someone they're wrong is useless. After that they can only think of reasons why they're correct.

chris_va 10y ago
I am not sure where I read the psych study (citation anyone?), but I remember reading that a really effective method for getting someone to change their mind was actually to get the other person to frame their argument as a question. E.g., "What questions would you ask me to convince me that you are correct?" It opens up the argument so they are less defensive, since they started with a question instead of an argument.
Retra 10y ago
I've learned plenty (and changed my mind many times) from having people simply tell me that I'm wrong.
- ehnto 10y ago
  I have found programmers to be far more receptive to blunt criticism than my other non-programmer friends. I think it's just a frame of mind to accept that will be wrong a lot and that is fine. It would take a whole lot of cognitive dissonance to get through a decent sized software project and imagine it is all flawless or couldn't be even slightly better in some way.
  - hcarvalhoalves 10y ago
    > I have found programmers to be far more receptive to blunt criticism than my other non-programmer friends. The work of a programmer is to sit in front of a soulless machine that has no inhibition in telling the programmer made a mistake on his code at regular intervals. You need to be pain intolerant to be a programmer, while in other roles pain avoidance is the norm.
    - namaemuta 10y ago
      Actually, a machine never accuses you of being the responsible of that error. It usually says "there's an error in the line..." but never addresses it towards the programmer even though they know that they are the responsible ones of that mistake. And in fact, that is one of the techniques of conflict management between partners, addressing the problem instead of finding the responsible of it.
      - shostack 10y ago
        Sounds like an opportunity for a more opinionated error logging tool... "@Dave, you seem to have made yet another type error on line 56. @jon recently committed code that didn't fail any integration tests. Why can't you be more like @jon?"
        namaemuta 10y ago
        Hmm... I wonder what would be the implications of one with positive reinforcement: "Wow @Dave! that's the smartest code I've ever seen! just one thing, there's a probably-not-that-important error on line 56"
        RodgerTheGreat 10y ago
        Positive reinforcement which is perceived as insincere will at best have no effect and at worst be seriously insulting. I can't imagine how an automated system which says vaguely positive things about code that it cannot understand would be seen as anything but insincere. If you build a system which successfully encourages actual humans to say nice things about one another's code _and mean it_ while incorporating constructive feedback, it would work beautifully, but that is a markedly more challenging problem...
  - thisone 10y ago
    If you think you are wrong, and someone tells you that you are wrong, you are being proved right. It's not much different to my mind, and I fall into that camp of people who always think they're wrong. Try to tell me I'm completely right, I'll argue with you why I'm not
  - sergiosgc 10y ago
    I have also found a "reverse" effect. Engineers in general (not just software guys), tend to not assign blame to errors, especially in panic situations. People declare errors as a matter of fact ("the database load is beyond the roof"), not as a result of wrongful actions ("your commit thrashed the database"). Both ends of behavior are the result of being confronted often with error, be it caused by wrongful action or caused by externalities. When a circuit goes up in smoke, its just physics being a harsh mistress; getting angry about it is useless, so we just skip the blame/anger part.
    - mcguire 10y ago
      I'm afraid I have to disagree, partially. In any given situation, you're right. But it's often necessary to get programmers to change their behavior, since what they are doing is causing the problems, and programmers are no better than anyone else at changing behavior in response to criticism. Design and code reviews are particular hot spots, which is why most I have seen had become just check offs.
  - emodendroket 10y ago
    Yes, but even then, they are often even more receptive to criticism that goes beyond calling them and their work stupid.
dredmorbius 10y ago
I employ that tactic as well, though even it fails to proceed with distressing frequency.

by jobu 10y ago

chris_va 10y ago

I am not sure where I read the psych study (citation anyone?), but I remember reading that a really effective method for getting someone to change their mind was actually to get the other person to frame their argument as a question. E.g., "What questions would you ask me to convince me that you are correct?" It opens up the argument so they are less defensive, since they started with a question instead of an argument.

Retra 10y ago

I've learned plenty (and changed my mind many times) from having people simply tell me that I'm wrong.

ehnto 10y ago
I have found programmers to be far more receptive to blunt criticism than my other non-programmer friends. I think it's just a frame of mind to accept that will be wrong a lot and that is fine. It would take a whole lot of cognitive dissonance to get through a decent sized software project and imagine it is all flawless or couldn't be even slightly better in some way.
- hcarvalhoalves 10y ago
  > I have found programmers to be far more receptive to blunt criticism than my other non-programmer friends. The work of a programmer is to sit in front of a soulless machine that has no inhibition in telling the programmer made a mistake on his code at regular intervals. You need to be pain intolerant to be a programmer, while in other roles pain avoidance is the norm.
  - namaemuta 10y ago
    Actually, a machine never accuses you of being the responsible of that error. It usually says "there's an error in the line..." but never addresses it towards the programmer even though they know that they are the responsible ones of that mistake. And in fact, that is one of the techniques of conflict management between partners, addressing the problem instead of finding the responsible of it.
    - shostack 10y ago
      Sounds like an opportunity for a more opinionated error logging tool... "@Dave, you seem to have made yet another type error on line 56. @jon recently committed code that didn't fail any integration tests. Why can't you be more like @jon?"
      - namaemuta 10y ago
        Hmm... I wonder what would be the implications of one with positive reinforcement: "Wow @Dave! that's the smartest code I've ever seen! just one thing, there's a probably-not-that-important error on line 56"
        RodgerTheGreat 10y ago
        Positive reinforcement which is perceived as insincere will at best have no effect and at worst be seriously insulting. I can't imagine how an automated system which says vaguely positive things about code that it cannot understand would be seen as anything but insincere. If you build a system which successfully encourages actual humans to say nice things about one another's code _and mean it_ while incorporating constructive feedback, it would work beautifully, but that is a markedly more challenging problem...
- thisone 10y ago
  If you think you are wrong, and someone tells you that you are wrong, you are being proved right. It's not much different to my mind, and I fall into that camp of people who always think they're wrong. Try to tell me I'm completely right, I'll argue with you why I'm not
- sergiosgc 10y ago
  I have also found a "reverse" effect. Engineers in general (not just software guys), tend to not assign blame to errors, especially in panic situations. People declare errors as a matter of fact ("the database load is beyond the roof"), not as a result of wrongful actions ("your commit thrashed the database"). Both ends of behavior are the result of being confronted often with error, be it caused by wrongful action or caused by externalities. When a circuit goes up in smoke, its just physics being a harsh mistress; getting angry about it is useless, so we just skip the blame/anger part.
  - mcguire 10y ago
    I'm afraid I have to disagree, partially. In any given situation, you're right. But it's often necessary to get programmers to change their behavior, since what they are doing is causing the problems, and programmers are no better than anyone else at changing behavior in response to criticism. Design and code reviews are particular hot spots, which is why most I have seen had become just check offs.
- emodendroket 10y ago
  Yes, but even then, they are often even more receptive to criticism that goes beyond calling them and their work stupid.

dredmorbius 10y ago

I employ that tactic as well, though even it fails to proceed with distressing frequency.