Comment by mistercow | Hacker News Reader

Comment by mistercow | Hacker News Reader

I find it frustrating how this article vacillates between "criticism" and "mean and/or unconstructive criticism". The article's thesis is that all public criticism is bad, but in supporting this, the author uses attacks that apply exclusively to unconstructive harsh criticism.

For example, while people may refer to a project as "their baby", the "calling someone's baby ugly" analogy stretches the metaphor to the breaking point. A baby's appearance is set and there was nothing the parents could do to affect it in the first place. Constructive criticism of a project, on the other hand, can serve to improve the project, as well as being instructive for anyone working on similar projects in the future.

Of course, the author then does say that "disagreeing" is OK as long as you do it tactfully. OK, fine. But that there's a word for that: "criticism".

Finally, we have this notion:

>Along this same idea, it is good to not talk about problems without offering up solutions. Doing this is called complaining.

Proposing solutions before discussing the problem is a cognitive antipattern (see http://lesswrong.com/lw/ka/hold_off_on_proposing_solutions/). If you try to solve a problem without carefully thinking about it and discussing it first, you will arrive at inferior solutions.

We should try to respect other people's feelings, but we cannot do so at the expense of progress.

At the same time, I think it's worth noting that a disturbing amount of the criticism made within the programming sphere is not aimed at solving a problem, but rather exposing the obvious wrongness of the original product and its author(s).

I fully support the idea of discussing a problem, but the key term here is discussion. Sitting around talking about how terrible component Foo is because it's obvious to even the most casual observer that it has not a single redeeming characteristic is strictly demonizing.

For me, it's all about the community. Recognize that every program we criticize almost certainly had someone pour a ton of effort and thought into it, and use that knowledge to temper your criticism. Make it a learning experience for the original author, and strengthen your team/organization while you're at it instead of tearing down people in the name of improving the project.

I completely agree. In particular, it's important to realize that it is possible to be mean and constructive at the same time, and that being constructive is not an excuse for being mean.

But to go so far in the other direction as to denounce all criticism is a huge error.

We might be mincing words here. But, I think we are agreeing on the basic idea. In my article, I am attempting to say "don't be mean, be nice, and provide positive encouragement, if you disagree, be objective and gentle." I think you are saying the same thing as well, but we are getting hung up on the word "criticism." This is of course my fault, because I was the one who introduced it into the original post.

One powerful set of words I have found when I disagree with someone's viewpoint or find what I perceive to be a weakness in their work is to say.

"Hmm, I like what you said X and Y, but I keep feeling like we might be able to figure out a better way to do Z. What do you think?"

Acknowledging what was good and attributing it to the person, but suggesting an improvement to what was less than good and taking partial ownership for the solution.

I didn't take away from the article a denouncement of all criticism. Perhaps I read into it what I believe, or was more charitable/liberal in interpreting/extrapolating the intended meaning from the clumsy wording.

Either way, my take away was that honest feedback and delivery/tone are orthogonal. You can be harsh in your feedback/criticism/expression-of-opinion, or you can do so in a way that disarms the other and is trust-building. The former is more likely to be ignored or misinterpreted, the latter is more likely to be understood. (The article presupposes this, and I agree. And one person's ability to take harsh criticism well does not translate to people receiving harsh criticism from that person also having the ability to take it well.)

If and only if you cannot find a way to convey your feedback in a trust-building way, the author asserts that your will be counter-productive in helping the other. Thus there are practical benefits to remaining silent, including: save your time/energy, not risk burning a bridge, not pointlessly inflict emotional harm (ok, the last one is not so practical as it is considerate).

But that's a very specific and unlikely circumstance, and the author explains in the article many simple techniques not to find yourself in such a circumstance.

Exactly, only you speak much more eloquently and precise than myself. Well put.

That was almost exactly my thoughts after reading the article. Almost, because I didn't know much about the solution proposal part, that's what I learned today.

But I don't think the author didn't know these. I think he did, but was trying too hard to defend Microsoft. If you take a look at the blog, it's not hard to see that he's a Microsoft fanboy. I'm not saying that to launch an ad hominem attack, or to denounce him. We're all fanboys, and that's natural. But natural rarely means the best that can be. He's a great example.

I'm really glad that I read the comments on HN before writing something. Feels good to know there are still sane people on the earth.

And here's the humor part:

"Don't report bugs on my software! It's my baby and don't you dare to point out its flaws!!1"

Reply on news.ycombinator.com