[Sprint]

The problem is that people are different. Some people will like the diverse community at HN to scrutinise their work to potentially improve it. Otherwise just want positive reinforcement. You can't really put both sides into the same bucket and decide that everyone should sugarcoat all the time.

I love criticising and my projects being criticised as long as there clearly is knowledge or experience behind. What if you see someone making a huge mistake based on your knowledge, should you stay quiet? Making sure that feedback comes across as nice and well-intended can be hard and time consuming for people who speak English as a second or third language.

So maybe there should be a differentiation between "Proudly presenting" and "Looking for honest feedback" somehow?

[roflc0ptic]

I don't think anyone is suggesting a lack of honest feedback. I don't like the phrase "constructive criticism" because it's been used into meaningless, but that's basically what's being suggested. Let me try an example instead of a definition.

Let's say someone is making a clear architectural misstep: They're trying to use python/django on a project, but their goals really require something like Tornado, and they're building themselves into a corner.

Maybe from where you're sitting it looks like an idiot mistake. The question is then, how to engage? Do you tell them condescendingly that only an idiot would misuse tools like that, and that they're foolishly the HTTP request/response model that Django implements?

Or, do you try to guess at where their knowledge fails, and give them links to writeups about asynchronous programming? Or do you engage them in conversation and try to ascertain why they're making the mistake, and gently explain that better programming models have been devised for the problem they're trying to solve, and why don't they look into it and see if they agree, and "by the way if you have any more questions here's my email, I'd be happy to help."

If people can't handle receiving this last approach, then it speaks to a certain lack of immaturity. If people can't handle acting taking this, it also speaks to a certain lack of maturity. We should try to build and enforce social norms that help growth as programmers and minimize conflict. Fortunately these goals aren't inimical; in fact, the more contentious the discussion, the less learning gets done.

[mandeepj]

You can always express your feedback/thoughts without calling other person an idiot/fool etc.

[dang]

I agree. It's important, and tricky, to strike the right balance. We're not calling for sugarcoating. That's why the last guideline says:

  When something isn't good, you needn't pretend that it is. 

I'm not sure it's best to have this as well, though:

  But in that case, consider saying nothing.

... because it slightly implies that criticism isn't welcome. Substantive criticism isn't the problem—gratuitous negativity is. So we may revise this.

Edit: We changed it to:

  When something isn't good, you needn't pretend that it is.
  But don't be gratuitously negative.

In other words, you don't need to sugarcoat, but nastiness is unwelcome.

The key word is "gratuitous". Substantive criticism is neutral and about the work. If it's personal or snarky, that's gratuitous.

[saturdayplace]

Those last two sentences might be worth appending to the guideline </2¢>