Hacker News Reader

Comment by BarryMilo | Hacker News Reader

Almost no one who is untrained in learning/psychology knows how to give feedback in a useful way.

For any such mentor, you can say "forget about the bad, focus on highlighting what the person did right". This will almost always dramatically increase the mentee's rate of progress.

This is because for any given task there are a million ways to get things wrong, but only one/very few ways to get things right. So people learn almost nothing from "don't". You can eliminate negative feedback altogether and lose almost nothing.

Of course, it can be useful in very specific situations, and these are generally not cases you need to sugarcoat because they are very technical (e.g. "don't spike the ball when leading by more than 14 points", "don't close the issue when a manager has commented on it", etc).

View on HN

Working in a small team and "negative feedback" / criticism is absolutely critical for us. For learning and improvement, to correct bad behavior and to write more robust code. But we are professional peers.

The issue with managers giving negative feedback is that they are either flat out not equipped to do so or they expect that their feedback can just be given without being involved with solving problems themselves.

What technical workers need from managers is that they explain problems _as is_. Then problems can be solved _together_, meaning behavior has to be changed up the chain as well.

For example it's completely useless and counterproductive to say "you're not on time" - yeah we know that. We don't decide not to be on time. Actually useful feedback is more nuanced and honest like "our customer wants to cancel that service they want to get rid of by end of the month, so they need time to enter this data by then. They only have two people working on that part time." - Now we're talking. We can talk about deploying a simplified, stripped down feature so we can take our time with the polished/richer version. One of us can schedule a video call with them to get them up to speed.

It's involving the _actual workers_ end-to-end that solves these kind of problems. Strip away the bullshit and the artificial metrics. Look at what needs to be done, what the actual problems are. Bring _that_ to us. Coordinate the right people (workers). Trust them to make sensible decisions and listen to their problems. That's useful _actionable_ feedback.

There's a desire for control that interferes with the actual job at hand. Let me gin up a metric for it and add that to your dashboard.

Am I the only one who thinks the opposite? The comments here certainly seem to indicate that. I think positive feedback is feel-good but ultimately useless (since my default is to just keep doing what I'm doing anyway, I don't need to be specifically told that), whereas negative feedback is actionable and can help me improve.

> This is because for any given task there are a million ways to get things wrong, but only one/very few ways to get things right.

Okay, but if someone doesn't get things right, how do you help them if you can't tell them what they shouldn't have done, and what they should have done instead?

Unless they’re really fucking up hard, there’s two consequences of not giving the bad feedback which I find acceptable:

- does it matter if they don’t improve fast enough in this dimension?

- they will improve by themselves over time. Encouragements are better than finding issues with someone.

> does it matter if they don’t improve fast enough in this dimension?

Improving fast is better than improving slow. This question presumes that improving (or the feedback that leads to the improvement) is somehow bad.

> Encouragements are better than finding issues with someone.

This is a false dichotomy, you don't have to do either one or the other. Also, "finding issues" sounds like you're assuming I'm trying to make up issues where none exist.

What's wrong with telling people where they could improve?

> Improving fast is better than improving slow.

See, I completely disagree with that statement. I think there is nothing wrong with being slow. Unless, again, it's fucking up with other people and you need to change your behavior.

> you don't have to do either one or the other

I would argue that yes you do. It's part of many company's manager training: you need to praise your employees. And it's also part of all the lists on burning out: not feeling valued.

> What's wrong with telling people where they could improve?

some people are not into self-improvement, or the never-ending quest of improving themselves. They just want to do their job, cash their paycheck, and go back to their loved ones.

> They just want to do their job, cash their paycheck, and go back to their loved ones.

Cynic warning. Why wouldn't they instead choose to work with something they enjoy doing? Is that just a euphemism for some people being so bad at what they do in general that no one would pay them for doing the things they enjoy, while they just pass the bar in some things (which they dislike), just enough for them to get paid? Because that would explain it.

Who said they don’t enjoy it?

Can it really be that decoupled from being ready and willing to improve? What's a skill you enjoy doing that you wouldn't want to improve on? I'm thinking a wide area of topics here from cleaning the kitchen to chopping wood to greeting strangers to writing software.

And the original question wasn't even about that, it was about receiving tips/pointers about improving. It doesn't have to be a "never-ending quest" (although isn't life supposed to be just that?). If you're doing some work, and someone points out how you can do it better, he's either wrong, or you refuse to improve... why?

One "why" is simply because people don't actually like doing what they do. They've simply accept it as a worthy tradeoff for the money they get/need. But they're certainly not willing to do any more than the bare minimum.

Do you have other "why's" that I don't see?

I mean sure, if you like chopping wood with a small axe between your toes and someone tells you that holding it properly with your hands would yield a better result then you're fine telling him that you prefer it your way (because you enjoy it), but if you work in a company where you're expected to perform up to a certain level then you can't really use that argument. Feel free to start a competing foot-chopping company!

A focus on where you can/should improve is definitely the most valuable, but positive feedback is part of that. Specifically, if you're actively working to address a deficiency, this is likely not true:

> since my default is to just keep doing what I'm doing anyway, I don't need to be specifically told that

I had reviews that were something along these lines in the past:

Q1 review: * "You need to work on your communication and keeping stakeholders in the loop."

[I move all design discussions from DMs to non-private Slack channels, post regular updates on Slack, and set up biweekly status update meetings on Zoom.]

Q2 review: * "Posting updates on Slack is nice, but not solving the issue." <-- Good to know, but less valuable information than: * "Using Slack channels + the biweekly Zoom updates have adequately addressed the issue."

TL;DR: If you've changed nothing, then positive feedback is useless. If you're experimenting with various solutions, positive feedback when one works is critical ['cause I'd drop Zoom meetings in a heartbeat if they proved useless].

That's good advice, thank you.

>This is because for any given task there are a million ways to get things wrong, but only one/very few ways to get things right. So people learn almost nothing from "don't". You can eliminate negative feedback altogether and lose almost nothing.

I would say, rather, that any "don't" should be paired with an "instead, do X when attempting to do <thing they were trying to accomplish>". "Don't do this one narrow thing" does very little to shrink their search space, while a concrete alternative does a lot, and is actionable.

(And yes, I've followed my own advice by saying "don't say 'don't', do it this other way instead"!)

Makes me wonder why the "say some good parts but also say some bad parts / things to improve on" thing gets perpetuated over and over.

Because it sounds reasonable. But it's gone into "trope level".

I like that million ways to do it wrong line. Never thought of it like that.

It's a sort of general principle and the first time I encountered it was in Anna Karenina by Tolstoy. It's the first paragraph:

> Happy families are all alike; every unhappy family is unhappy in its own way.

Indeed, it's why an exit code of 0 indicates a successful program execution, whilst anything else is an error code (which other programs can compared against known values, if appropriate).

You've given me hope that, one day, all the great Russian novelists will be translated into POSIX. :)

I think it applies personally as well as to families; you can be excited for an event, but you can worry about your clothes, your hair, your shoes, your smell, your smile, your voice, your style, etc. etc. It's very unlikely that you will be excited for your clothes or your shoes or your hair. So there's one kind of happiness but many kinds of anxiety. Similarly you can be content with your life, or discontent with your finances, home, relationships, etc. etc.

Same as a computer system has one way that works, but many things which can go wrong.

It's why entropy is a thing; there's only a few ways to build a stable structure, but zillions upon zillions of ways to build a crumbling pile of dust. Almost any change from wind/pressure/radiation will move it towards a less structured state.

It's related to why the Pyramids are so stable, they are shaped like the aftermath of a fallen building, a pile of stone can't easily collapse any further.

I guess thats the same reason cords tend to tangle. There are many many ways for a cord to become disordered or form a knot. There are very few ways for them to be ordered. Hence untying corded earbuds everytime they come out of your pocket.

Reply on news.ycombinator.com