Critiquing is a skill. The onus is as much on the critiquer to formulate their critique in a constructive, actionable way as it is on the critiquee to take the critique in stride.
That said, good crit skills are very hard to develop, and environments where effective critique sessions can be carried out very hard to build (because it’s fundamentally about trust). And it’s skill that is just not taught in engineering; people familiar with critique will be mostly people who went to art school, and even then many art schools do a pretty bad job at teaching it (I had a design teacher who, during critiques, would make students... vote on their favorite /facepalm).
Sure. However, to get feedback for a new project you probably need all you can get. Getting any at all can be surprisingly difficult.
Therefore one rarely can throw out the negative comments. Perhaps copy them to a file of notes and edit them to their core essence to minimize the sting.
Feedback from total strangers is overrated. You have no clue where their feedback comes from (are they a prospective user? Some grumpy programmer who just wants to rant about your choice of framework? A product designer used to operating in a certain environment that just doesn’t apply to you? etc). Separating the wheat from the chaff from anonymous posters is tricky business.
Thinking of it as good feedback vs bad feedback based on the feedback itself is also not the right way to go in my experience. Good feedback is anything that observes the way a particular problem was solved, and proposes an alternative way of solving it, or reframes the problem altogether (identifying a problem that was not solved can be valuable too, although the line is blurrier). Bad feedback tends to be, well, anything that is not that.
