
Negative Feedback Is Positive - davnicwil
https://davnicwil.com/negative-feedback-is-positive/
======
atoav
As long as it is somewhat honest or _qualified_ negative feedback this is
true.

As someone who studied film, trusteothy sources of negative feedback can be
extremely valuable and hard to come by. Many people will just tell you how
well you did, while you might just need a honest judgment.

Taste however is different. You can e.g. make the best cli app in the world,
you will find a ton of people who give you negative feedback just for it not
having a GUI. This is why it is useful if you know your critics at least so
much that you can judge where their feedback really comes from.

So the honest opinion of someone using CLI software for the past decade is
more valuable if you're working on such a thing, than the honest opinion of
somebody who dislikes CLI software altogether or has no idea at all. That
doesn't mean these people cannot provide valuable criticism — only that it
should be taken with a grain of salt.

~~~
sovok_x
People criticizing a good console application for lacking a GUI indicate need
for such a GUI, this is not criticism per se. It is useful information too.
But many developers just don't have necessary time or will to code it and this
needs to be conveyed. Proper communication is the best thing humans ever
developed.

~~~
codegladiator
> just don't have necessary time or will to code

Or the intention to begin with, which is the situation OP points out as non
useful negative criticism.

But yeah, I don't see "request for gui" as a criticism for a cli application.
More like a feature request.

~~~
mitchty
Well it might be more than just a feature request.

Think along the lines of wireshark, you can separate out the underlying code
to do the work in a library, then use that in a cli and gui. If you're working
on a cli app yourself, that "feature request" might hit things you just don't
have the will to do. I know me making any sort of gui is going to end up a
tire fire, and the work to cleanly separate out the code from the cli to a
library usable by both is also a bunch of work for what appears to be a at
best nice to have "feature".

~~~
codegladiator
> you just don't have the will to do

Sure, will to do, is one thing. Consider I request the curl dev to make a gui
for it. would you find it unreasonable because everyone is okay with cli ?

I just cannot justify any reason apart from the convenience of using gui to
develop that.

> separate out the code from the cli to a library usable by both is also a
> bunch of work

The time and amount of work is in my opinion not just about the amount of
work, because if that was the case why develop even the cli and opensource it
?

Make a GUI is just a different beast compared to CLI.

~~~
mitchty
> Consider I request the curl dev to make a gui for it. would you find it
> unreasonable because everyone is okay with cli ?

Yes, as libcurl exists and gui's can be done by someone else more
knowledgeable with them. Plus gui's for what exactly? The web? macos? windows?
X? playstation? even asking for a gui is a bit vague and an incomplete request
I would reject outright without at least going: i want this.

I'd solve this by going, sounds good, you're the best person for it so far and
now have write access to create a branch and get us there with the itch to
scratch it.

> Make a GUI is just a different beast compared to CLI.

Agreed, but the effort can be disproportionate to the gains the submitter
might get. And if this is something i'm doing for myself, to be blunt, I don't
got time for that kind of effort. And more bluntness, nobody could make me do
it, my time is my own and I have to balance that against other things. If you
ask for it you better believe I'm going to say its now on you to do as I have
neither the skills nor desire to invest my own time on this. I'll gladly help
you out getting there but that is about as far as I'm willing to go.

I feel that is fair. Others may disagree.

~~~
codegladiator
I think you are just agreeing with what I said.

> Plus gui's for what exactly

GUI is a huge separate feature request and not "criticism" per say.

> but the effort can be disproportionate

Hence the different beast.

Like I said, I just cannot justify any reason apart from the convenience of
using gui to develop that.

~~~
mitchty
> I think you are just agreeing with what I said.

Pretty much yep! I think we both agree asking for gui support is likely to get
shot down by most maintainers. And not for any reason than its a big ask.

> GUI is a huge separate feature request and not "criticism" per say.

I've seen a lot of people even on HN complain about cli only things. I'm not
sure everyone would agree its a feature request.

------
philliphaydon
I heard a quote many years ago. I don’t remember where from. But it was
basically:

“Negative feedback is the best feedback because it helps you improve the
things that annoy your customers that no one else is telling you about.”

A lot of companies hate negative feedback though and get upset. But if I ever
tweet something saying it’s shitty or doesn’t make sense. If they reach out I
always try to give them more info and clear reasons why.

Most recently I complained about a survey tool because it asked a question but
the design of the form didn’t show an input field and I didn’t know where to
enter data. So I pressed enter wanting an error message or something. And
instead I got taken to the next question.

Turns out it was a display issue in any browser other than chrome. But they
reached out and I explained and they thanked me and said they will look into
it.

It must be hard for people to filter through the negative stuff for valid
criticism though.

------
msla
"Negative feedback" is _not_ positive when it's merely an insult.

Let me clarify:

"Your app is so slow it's proof you have absolutely no business writing
software and evidence of the moral decay of the entire field of computing, if
not humanity as a whole. Give up. You deserve a six-foot nap." is not merely
an insult. It contains an actionable point.

"You have absolutely no business writing software. You're a monster. You do
not qualify as human. I would like to see you in an immense amount of pain."
is most definitely negative feedback, but it does not contain anything
actionable. It has no positive aspect to it.

The fact unquestionably sane people can generate feedback of the second kind
is one of the things to consider when accepting feedback.

~~~
luckylion
> The fact unquestionably sane people can generate feedback of the second kind
> is one of the things to consider when accepting feedback.

It's easy to drive people to (temporary) insanity, too.

A recent anecdote: PayPal sucks (as usual) and doesn't let me log in. They've
been requiring me to change my password before because of some strange
Californian paranoia, so I hope that'll help and reset my password
successfully. I still can't log in. I'm looking for ways to contact customer
service. It says "log in, then use the contact options to send us an email".
It has a "can't log in? call us!" option, I call them, sit through an annoying
60 second phone menu, only to be told that they're not working right now and
to call back on monday. I notice that their "password was changed" info wasn't
sent from a no-reply-address, but some service-email, so I just reply,
annoyed. I get an auto-reply, saying "to send us an email, please log in ...".
Needless to say that I never heard back from anyone.

It's such a broken process by a global corporation and it was so annoying,
that I was pretty close to just responding with insults, but I'm trying to
control my emotions, and also I still need my PayPal account.

AliBaba/AliExpress is another example, they use (used? haven't tried in a
while) chatbots pretending to be human support agents, and they're so bad at
it that it's a) absolutely not helpful for most cases where you need support
b) easy to spot. The insulting part is that the (clearly labeled) first
response chatbot says "let me get you a human agent that can handle this",
only to put you into contact with another copy of itself that asks the same
questions. The part that really makes me want to scream at them: their bots
have artificial "thinking time". They'll say "one moment please", have typing
indicators, only to say "you're asking about '$keyword', right?".

Very strong negative feedback could just mean that you're _really_ messing up,
or the way you collect feedback is broken. Have a form that only accepts 200
characters in the message field but only says so when you submit and resets
the form? You won't get a lot of friendly messages from people that had just
written long bug reports or messages.

------
dahart
From experience doing a startup and seeking feedback on a new product, I think
this is absolutely true. Some people here are saying the feedback needs to
have substance or not just be insults, but even those are meaningful. Your job
is to read between the lines. The real question you need answered isn’t the
same as the question they answer, so you always need to think about how to
translate their answer into priorities.

Even no feedback is positive feedback, because it’s telling you that people
aren’t in love with your creation the way you are, and you then need to find
out why. When I created a web app, I solved the problems that I strongly felt
needed solving, and then I found out that maybe 5% of my audience agreed with
my choice of priorities, and 95% of them cared deeply about things I hadn’t
considered carefully.

There’s a corollary for startups that negative feedback from investors is also
positive. The second best thing an investor can do is say no (where the best
is yes & a check). They hardly ever say no. They usually say come back with
such and such improved metrics, and we’ll talk again. When they say no, it
gives you valuable information, and it releases you from chasing something
that’s unlikely to work out. When I was pitching, I was so thankful to the
couple of investors who said no and gave direct feedback about why. That was
some of the best feedback I ever got.

------
Kiro
As a game developer I don't really listen to feedback. Gamers' feedback tends
to be very short-sighted and even harmful. If something sticks around as a
common complaint I may consider it but even then it may not be a good idea
(e.g. a feature that may seem obvious can mess with another planned feature in
the roadmap or be automatically fixed due to reworked mechanics).

~~~
KineticLensman
I've found that feedback from playtesting is always worth listening to,
especially if it highlights issues (e.g. with game mechanics or balance) that
weren't obvious to me as the game dev. This is an instance of the more general
process of getting users who aren't the dev to help test a system, e.g.
because they will take unexpected paths through.

------
megavolcano
Now someone please explain to my boss that "you don't listen" and "can you
just do your job properly", when he doesn't lay out the correct requirements
and expect us to read his mind is not proper "negative feedback".

~~~
wruza
If that helps, I usually draw a big picture, fill in all the details and show
where inconsistencies, gaps and future landmines are. Then come up with few
detailed suggestions, workarounds and/or hypothesis on these, all easy to
answer with yes/no. Usually that discovers an entire layer of problems in the
original problem statement and the cycle repeats.

Sometimes though they fail to even yes/no and just repeat what was said
before. A little patience and time is required to bring that in their mind
clearly.

I think an advice could be, don’t bring emotions to the table and try to solve
this bigger task of getting shit done in machine+human environment rather than
locking yourself in a strict requirements bunker. Connecting ideas to reality
can already be incredibly hard and more so impossible without your help.

------
anonsivalley652
Ask people something to the effect of:

 _How does this suck?_

The goal is to disarm people so they're able to criticize something without
worrying about saving anyone's face. Separate people from ideas... as much as
inhumanely possible to get honest feedback.

I must always remember also: don't fall in love with or lionize any particular
idea, creation or plan because they're not my children and are ultimately
stuff and/or configurations of concepts. In the bigger view, ego death and
detachment are important because if someone lies to themselves, for whatever
reason/motivation, they're going to lie to everyone else too. Single founder
tend to have more "grand big idea" insanity that needs to be tempered with
other founders, family, friends and/or users who aren't dripping negativity
but who don't applaud them if they can't sing like those people who go to open
mic nights and screech. Don't be that guy or that founder with a Jump to
Conclusions mat.

------
cousin_it
Any thoughts about the norm of "constructive criticism"? I think it's partly a
good idea, because the feedback-giver can take a little trouble (propose
improvements along with criticism) that will save a lot more trouble for the
feedback-receiver. But also partly a bad idea, because I've seen people defend
pointless bureaucratic procedures that shouldn't even exist, by saying "don't
say our procedure is bad, say how we can improve it". So it seems that
"constructive criticism" is partly a good idea and partly a kind of groupthink
practice, but I'm not sure where to draw the line.

~~~
lostmyoldone
While I feel I only partially managed to capture how I think about it, because
I surely have thought about it a lot, as I've seen places where critique flows
like water - easily and without much strife to anyone - and places where any
critique is/becomes either a disaster - or completely ignored!

\--- Constructive criticism as such might be a sensible ideal when giving
unsolicited criticism, but it also terribly destructive as an expectation, or
norm.

In many cases the call for constructive criticism is nothing else but a very
effective form of censoring as t makes any criticism from anyone that hasn't
got the necessary knowledge, or time that be able to find and elucidate the
solution to be completely dismissible without consideration.

Not at all what one wants, unless you want to suppress "dissent".

Requiring only constructive criticism could perhaps acceptable as a very
temporary intervention when all else have failed. In any other case it almost
certainly devolves into _some kind of_ censure.

This does not imply that the one critiquing is free to do or say whatever they
want, not at all!

Honesty, a constructive _intent_ , avoidance of ad hominems, engaging without
prestige or appeal to authority, and a substantial amount of intellectual
integrity is always going to have to be required of anyone giving or accepting
critique - if it is to be truly useful.

Moreover, I would claim that sustainable and effective criticism in a
professional setting must also be accompanied by an almost complete lack of
subterfuge. Especially any kind of hidden attempt to cast yourself in a better
light, or someone else in a worse.

Getting to be able to sustain effective criticism can lead to a higher ratio
of constructive criticism, but I haven't seen anything suggesting the reverse
to be true unless the basic values of honesty and integrity are given equal
consideration and prominence.

Critique must be expected to sometimes be painful in some - often obscure -
way, so what we can do improve how we handle it is most easily explained from
the perspective of taking away what makes us fear this particular form of
pain.

Sometimes fostering a good climate for criticism seem to be about almost
everything but the critique itself.

------
zozbot234
I would say "negative feedback is usually good news". Positive feedback is bad
news. The vast majority of control systems in the real world are usually based
on negative feedback, not positive feedback.

You only really need to provide "positive" feedback as part of stabilizing an
unstable system - like countersteering when driving a car. And then if you do
it properly it kinda turns into its "negative" anyway.

------
beardedman
A personal pet peeve of mine is that people sometimes ask rhetorical questions
- rather than simply state what the problem is. Drives me nuts. For example:
"Why doesn't this button submit the form?" vs "I don't think this button
works". I see this all the time and still scratch my head.

~~~
ironmagma
There are downsides to saying “this button doesn’t work” — there’s a follow up
question in some cases, which is “what makes you say it doesn’t work?” Asking
the question acknowledges that there may be a lack of understanding of the
intent of the button. Maybe to you it doesn’t work, but to the person who
designed it, it is working as intended, and your mental model is the incorrect
part. Asking the question as framed directly in the way you experience the
world (action not leading to an expected reaction) makes the problem statement
more clear.

~~~
hinkley
What do you think is more reasonable? Asking hundreds of thousands of users to
learn to give better feedback, or for hundreds of developers to learn better
listening?

~~~
loopz
The problem here is a meeting of minds: The user can't possibly know what is
expected behaviour, especially with the modern lack of GUI standards. A tester
might be able to read a user manual, but the manual might be wrong. As dev,
you're the vendor. Some maturity is expected and that you're able to figure it
out.

What helps is reaching out to users earlier and agree on behaviour together.
You know, using agility.

~~~
hinkley
It’s a pretty sophisticated skill to hear aggression in others and be able to
hear what is causing them pain instead of just “I wanna fight.” But aren’t we
problem solvers by trade?

Problems make people upset. If you can only treat polite customers you’d make
a terrible health care professional or even plumber. Someone once gave me the
advice that part of why developer salaries are so high is because they include
hazard pay.

I suspect the same is true for plumbers. $300 to get my plumbing unplugged on
a Saturday night can probably smooth a lot of feathers with his family. And
that was a slight discount, probably because I was pleasant, instead of
railing at his whole profession for a problem he didn’t create.

It’s hard to remember this sometimes, but I do think it provides some
perspective.

------
Z1515M8147
In systems engineering, negative feedback is viewed as one form of
'unexpressed system requirement' for that stakeholder. Surprise negative
feedback can be even better, as it may be a sign that your system has a
stakeholder you weren't even aware of but which you now are.

------
artsyca
I've known this for ages it goes without saying that in real design when you
show your work to another designer they're meant to find the one thing that
sticks out and the more brutally honest the better

------
gumby
People will rarely tell you to your face that your “baby” is ugly. For actual
babies this is a good thing, but in business this can lead to much wasted
effort.

------
melling
Pay attention to negative feedback and solicit it, particularly from friends.
Hardly anyone does that, and it’s incredibly helpful.”

— Elon Musk

~~~
FartyMcFarter
Very good quote. However, I'm not sure that he practiced that enough, given
for example his repeated online bullying of the diver (which should have been
corrected after negative feedback).

------
michaelbuckbee
Here's what I've found as effective ways to give (and receive) negative
feedback.

1\. TRUST - I'm part of a tight-knit group of bootstrapper/indie devs and a
real aspect of how we're able to offer real feedback is that we have the
backdrop of knowing each other in other ways.

If someone who I consider a fantastic developer and sent me a Christmas card
last year tells me: "Mike, this makes no sense." take that a lot more
seriously.

2\. DATA - as a human I've found that I'm often wrong, so I try to evaluate my
own opinions against data. In the context of apps/sites this is often A/B
tests or other quantifiable things.

3\. FEEDBACK NOT ACTION - People tend to offer feedback along with a kneejerk
suggestion on what action to take to resolve it.

Example: I had a service that required users to OAuth (with a bunch of
legitimately scary permission scopes) and also make DNS changes to enable it
and was told repeatedly as feedback that it was "too much" and "people would
never use it".

Their recommendation: shut it down.

The direction I took: go crazy building trust in the process.

The result: my most successful project to date with thousands of paying
customers.

3\. SCOPE - feedback is often scoped improperly. Is someone asking for
feedback about a startup idea: "Will this connect with people?" it's not
useful to critique the fonts used on their homepage or something else. (both
HN and I are too often guilty of this).

4\. BELIEVE FEEDBACK - one of the most important exercises I do for all my
projects now is a "UX walk through" where I sit someone down and just try and
let them sign up and work through the process of signing up for the service
with as little intervention from myself as possible.

I find it incredibly painful.

Even interfaces that I think are incredibly polished and straightforward
suddenly become opaque nightmares when presented to people that haven't seen
them before. This is the "curse of knowledge" \- I'm too close to the process
and can't see the issues clearly.

In these situations, it's incredibly easy to argue with people about it and
say: "how can you not have seen that button?" or "You're not really paying
attention" or something else dumb.

But if I'm able to make myself believe the feedback, not take it personally
and really address the issues at hand I find I get fantastic results. Last
time I did this I ended up scrapping months of works (painful), migrating to a
new auth system (painful) and rebuilding the entire onboarding from scratch
(incredibly painful), but the end result was a move from 30% successful user
onboarding to over 70%.

Feedback works.

------
ben0x539
Uh, this post sucks! Am I doing this right?

