Negative Feedback Is Positive
davidnicholaswilliams.com
davidnicholaswilliams.com
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.
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.
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".
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.
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.
> 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.
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.
This kind of criticism is even less useful if you are doing e.g. music. Let's say you are part of a Death Metal band and ask for criticism on your music because you want to get better as a band.
The most useful (negative) critic will be a friend who has been listening to Death Metal for years, plays it themselves, has a open mind about different genres, knows what you're after and still will give you the straight hard truth.
The least useful negative critics will be the ones who say they don't like metal and think your music is too aggressive or the metalhead who wants you to do another subgenre of metal because they like that more.
Music of course is more based on taste and subjectivity than software development should be, but one can transfer at least some of this idea: people will often argue from the perspective of their preferences, completely ignoring the scope and goals you publicly stated. And if your goals as a software developer don't align with your critics preferences, their criticism can lead you astray without you noticing it.
It can still be calid in terms of redefining your scope or expanding your goals, but it doesn't help you to get better within them.
Good negative criticism takes seriously what you wanted to do (if it makes sense!) and jelps you to get better at that.
“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.
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.
But it is also true that there are crazy and inadequate people out there that either respond randomly or have unrealistic expectations. Their replies can be considered somewhat positive too - they indicate that people use your product. If your product doesn't attract crazies by design and is not a totally unusable, deceptive and buggy garbage they usually represent only tail of your userbase distribution.
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.
If you have a blue website and constantly get feedback from people saying they love blue then you didn't need the feedback.
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.
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.
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.
--- 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.
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.
What helps is reaching out to users earlier and agree on behaviour together. You know, using agility.
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.
It helps to explicitly ask about this from end users when you have a bug reporting form.
I find, when there's no common context, I have to reach out and spend some time with the person anyway. Usually you gain new insights, relationships and improved common understanding. Feels almost humanizing and well worth the time spent.
There should be distinct progress indication for long operations and human-readable feedback for every failure mode, even if simplified, to avoid overwhelming users with difficult terminology.
Loads of error scenarios come up once in blue moon, details for those you should have in application logs that should be analyzed by technical support. Usually user cannot do much about those, like some service is down. Information about some specific service not working for users means your application is down, so it does not matter.
Then you have failure modes that happen often, like users getting data from outside system where your business rules do not allow for that data. In that case user has to be provided with information what he can fix, "Operation is not permitted because we operate only on yellow cars, buy a yellow car please".
In the end technical support should triage issues and invest time on specifying error messages that can help users skip technical support. It is a waste of time to come up with all errors explaining some details.
If service is down users should know it is down and it is not a failure of their device or network connection. It is normal to skip specifics that developer need for debugging but simply indicating a failure will just annoy users because they won't know what they could do. And contacting support each and every time is tiring and counterproductive for everyone involved.
It can be error code or somewhat generalized textual description but it gives users feeling of control which most people like to have.
How do you know that this button does not work? Maybe the form has some field that does not show validation message.
Usually when users say with confidence that something does not work, it turns out that something else does not work and that button they mention is perfectly fine. In most of cases users just expect something else because they don't understand the system.
— Elon Musk
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.