Where Criticize Bluntly Works

Indicators of situations when CriticizeBluntly might work:

when the subject matter itself is very unforgiving of errors (maths, chess, logic, ...; especially anything dangerous, such as diving, fighting, ...)
when there's a lot of respect for the person doing the criticizing, especially...
- in a teacher-pupil relationship or...
- in an established peer relationship
when the answer/statement/solution being criticized is either factually, objectively, provably wrong or right (and may be defended as such)
when the subject matter is unlikely to provoke strong emotions
when you are face-to-face (where you may more easily correct mis-communications)
in a setting where the person being criticized feels secure enough to accept the criticism (their job is not on the line, they don't feel compelled to "defend their professional honor" in front of others etc.)
when the person criticizing doesn't mind giving offense
...

One example in support of the fact that CriticizeBluntly can, in fact, work:

In school, we had one outstanding maths teacher. One of the things he did was being very exact and unforgiving in evaluating one's answers, even during normal class discussions:

: Teacher: [asks difficult question, the answer to which is the opposite of "negative"]
: Me: "Positive?"
: Teacher: "Wrong."
: [astonished pause, much thinking...]
: Another pupil: "Not negative?!"
: Teacher: "Correct."
: Me: "But that's what I said!"
: Teacher: "No, that's totally different from what you said."
: Me: "...?"
: Teacher: "'Not negative' includes zero, 'positive' doesn't."
: Me: "!"

With him, we learned to be mathematically exact - and more students walked out of his exams with perfect scores than with any other teacher. A lot of us discovered that we actually even liked maths. ;-) --FalkBruegmann

You teacher needs to go back and study set theory if he thinks the two answers are totally different.

This example worked, for you, because there was someone else to provide the correct answer. Take the other pupil out of the scenario and what do you have: a guessing game with zero feedback. Imagine instead if your teacher had said "Almost, but wrong"... from that bit of feedback you could then reason that the correct answer couldn't be negative or zero or infinite, because none of those are "almost" right. Being "almost" right means that your answer needs it's boundaries shifted a little bit ... and getting you to think about boundary cases is much better than forcing you to just take another blind guess.

Sorry, I have to disagree. If he had said, "Almost, but wrong", I would have corrected my answer and immediately forgotten the incidence. The answer "Almost", between the lines, reads "It's OK and good enough to be almost correct."

On the other hand, the answer "Wrong" also says: "This is maths, and here, there is no such thing as 99% correct, only pure mathematical truth. It is possible to achieve perfection here, and I expect you to. More than that, I think you can achieve it on your own, without hints and corrections." --FalkBruegmann

by resorting to guesses or hoping someone else has the correct answer?

: I dare say you would be disabused of that misassumption ["It's OK and good enough to be almost correct."] when you get your test scores back with Almost, but wrong - F

That's the point, exactly. Other teachers were more lenient in the classroom discussion than in the exams. This teacher was so demanding during "training" that we found the actual exams to be easy. --fb

Costin, is this similar to what you experienced with your chess teacher?

Actually my math teacher in high school was exactly the same and more, and he wasn't particularly polite when student made mistakes. But he was extremely talented, and it helped us a lot. My chess mentor distinguished himslef by a very acid form of irony, which was very good to shake one's spirit.

You can add SoftwareDevelopment on the list of unforgiving domains. It is very unforgiving to make mistakes, with all the XP and refactoring , mistakes in SoftwareDevelopment cost a lot, sometimes the whole project. And UNLIKE in maths and in chess, there's tons of bad advice floating around in every imaginable shape and form (magazines, vendor marketing, vendor documentation, published books, online forums, blue prints, sample applications, you name what here). And also UNLIKE in maths and in chess (and other domains) CriticalSpirit is not quite encouraged.

I wouldn't think it is good to place too much emphasis on the security of the person being criticized, (let the other save face kind of thing), a much more important thing to consider is the disastruous effects his bad advice might have on others. This is a lot more important than anyone's ego. --CostinCozianu

I disagree. There are a lot of cost-benefit trade-offs in SoftwareDevelopment that make distinctions about the right and wrong thing difficult. Microsoft and others are notorious for delivering imperfect code on time because of considerations irrelevant to programming.

With what exactly do you disagree ? Is critical spirit encouraged by the industry, is critical spirit not needed in the industry, is anyone person's ego more important than the disasterous effects his bad advice (sometime advice means books/standards/product docs/official recommendation or guidelines) might have on others, or is it just that CriticizeBluntly is not recommended in discussing SoftwareDevelopment issues ?

CriticizeBluntly is not necessarily about right and wrong, on the other hand there are things that are clearly on the wrong side.

How about this: If you can show me the economic advantage that "encouraging CriticalSpirit" gives one company over another, I'll agree that we should do it.

Specifically, in SoftwareDevelopment, you might come across this situation: Programmer P is working on fixing feature F. Manager M has to meet deadline D. M says to P, "I know you're working on fixing F, but the bug isn't big enough to hold back the release." P, knowing the 'right' way to program says, "It would be a mistake to deliver without fixing F." M, knowing the 'right' way to deliver software says, "No, you're wrong." P replies, "No, you're wrong." What's the economic advantage of having this argument?

Who's right? Who's wrong? Does it matter? Perhaps they deliver the broken software, and somebady dies (in a fluke accident). Was the manager wrong? Suppose it's the exact same software and nobody dies. Was the programmer wrong? It's impossible to be certain one way or the other. Criticizing bluntly in this case will only spark a useless argument. In the end, someone has to make a final decision that may be 'wrong' or 'right'.

The futility of the imagined argument above doesn't come from its bluntness; it comes from the lack of useful information being offered. Blunt means direct, not rude or irrelevant.

See WhereCriticizeBluntlyDoesntWork

CategoryCriticism