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.

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

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.

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.

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.

> 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.

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.

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?"

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"

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...

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

Yes, but even then, they are often even more receptive to criticism that goes beyond calling them and their work stupid.

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