8 ms·

The best advice I received on this topic was that feedback should be actionable, specific, and kind. Actionable and specific mean that the person on the receiv

by donw 10y ago

The best advice I received on this topic was that feedback should be actionable, specific, and kind. Actionable and specific mean that the person on the receiving end has a set of concrete actions to take to implement. For example, "get better at programming" isn't specific, and "get a PhD in Computer Science" probably isn't actionable, but "work on improving your ability to write readable code by working through the exercises in this book" is something that can be worked with (especially if you can spend some time to mentor that person!) Kindness matters a lot, though, and it is different from niceness. When giving feedback, some people say that they are brutally honest, but often the emphasis is on the first word, rather than the second. Things like "The module you wrote is crap because your code sucks and is hard to maintain." doesn't help in any way, shape or form. On the other hand, others that focus on being nice often heap on the praise, while excluding or downplaying the criticism. "You worked really hard on that module, and maybe should should spend a more little time refactoring and cleaning things up" is too nice. Kindness means sharing the good and the bad, but without being aggressive or accusatory: "Thanks for the hard work on that module. It does exactly what it needs to, but I'm really struggling to understand what's going on in there, as there are some really big methods and classes. Breaking those apart into smaller separate objects and functions would help a lot."

tedmiston 10y ago
> When giving feedback, some people say that they are brutally honest As someone who prefers giving and receiving terse feedback... I would suggest that there's nothing wrong with brutal honesty for type of people who appreciate receiving it. If I write code and forget to test some specific cases, I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version. I don't need to hear compliments on what's right... just what can be improved. Some people really value bluntness and see directness as more friendly because it's honest.
- donw 10y ago
  Terse feedback can be fine, once you know that, for a specific person, terse feedback is effective. I have met more than a few people that said they preferred "brutal honesty", but would still react very defensively to straightforward, terse feedback. Being terse without seeming to be on the attack is very difficult, and it is human nature to defend ourselves -- and stop listening! -- if we perceive that we are being attacked.
- wpietri 10y ago
  > I don't need to hear compliments on what's right... just what can be improved. I used to say the same thing, but now I think I was wrong. I didn't want to hear compliments on what's right. But I did need it. Focusing on negatives helped me reduce error rates. But ignoring the positives limited my ability to grow. What got me to slowly switch was learning about appreciative inquiry. It's a practice of focusing strongly on the good aspects of something and seeking to amplify them. I looked into it because a team I was working with had these brutally negative retrospectives. They were in a rut of flagellating themselves every week about all their failures. They were a great team, but weren't performing well because they became gradually more stressed and discouraged. And after I saw that in them, I eventually saw it in myself, too. I'm now 6 or 7 years into consciously switching approaches and I'd never go back. Just today I was pairing with a younger programmer, and we even took some time to appreciate their anxiety. That fear of failing was causing them a lot of problems, but instead of asking them not to worry, I asked them to channel their anxiety into areas where it was useful, like writing good tests. That said, I'm with you on not wanting "nice" versions of things, which I see as a social performance, and not actual kindness.
- TeMPOraL 10y ago
  > for type of people who appreciate receiving it This is key. I wonder though, what's a good way to signal that to friends and coworkers? I personally declare Crocker's rules[0], but I rarely have the opportunity to communicate that to people I'm talking to. [0] - https://wiki.lesswrong.com/wiki/Crocker's_rules https://wiki.lesswrong.com/wiki/Crocker's_rules "By declaring commitment to Crocker's rules, one authorizes other debaters to optimize their messages for information, even when this entails that emotional feelings will be disregarded. This means that you have accepted full responsibility for the operation of your own mind, so that if you're offended, it's your own fault. The underlying assumption is that rudeness is sometimes necessary for effective conveyance of information, if only to signal a lack of patience or tolerance: after all, knowing whether the speaker is becoming angry or despondent is useful rational evidence. Two people using Crocker's Rules should be able to communicate all relevant information in the minimum amount of time, without paraphrasing or social formatting. Thus, one who has committed to these rules largely gives up the right to complain about emotional provocation, "flaming", "trolling", "abuse" (hopelessly subjective terms) and other alleged violations of etiquette. They give these rights up in the interest of effective debate."
  - gbog 10y ago
    I don't think being blunt is more efficient. First, adding a few "kind" softener words do not really take so much time, don't you think so? Second, efficiency in human to human communication is not only a function of raw information density. Adding well chosen "kind words" may allow the reader to get some context and a better understanding of the message. A simple example: say you already communicated with the guy in the past. If you add a reference to this previous communication, the reader will remember you better and adjust the frame. There's so many things passing through language, many are very volatile but still important. We're not computers. Human language have very little in common with computer languages.
    - TeMPOraL 10y ago
      I think it's already captured in Crocker's rules definition - "one authorizes other debaters to optimize their messages for information, even when this entails that emotional feelings will be disregarded". It's not about being rude for the sake of being rude - if a kind word provides some context best, a kind word should be used. The idea here is to free your interlocutor from having to constantly censor their communication in order not to accidentally offend you.
- morgante 10y ago
  I think one of the important takeaways from the talk is that even if people say they want brutal feedback they probably don't. More importantly, feedback can be totally honest without compromising it's optimism. > I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version I agree that niceness isn't always necessary. Fortunately, that's not what the talk is about. For me, the examples you gave actually fulfills all the criteria for optimistic criticism: - It's impersonal: the focus is on what the code is missing, not your ability as a coder. - It's specific: there are hyper-specific criticism. - It's temporary: the tests are merely "missing" and that's a condition that can be quickly changed.
  - tedmiston 10y ago
    This is a totally valid point about my example. Unfortunately for the sake of my argument, it was done by accident (or subconscious). I have been practicing detaching critical feedback from the person and instead attaching it onto the situation or context for quite a while now. In any form, I think that point is crucial.
- aninhumer 10y ago
  >I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version. Could you give an example of what you're imagining a longwinded nice version would be like? Because this seems mostly fine, just a bit clipped. All I'd really expect to improve it is something like: "This is mostly fine. It just needs tests for negative numbers, empty strings and null." Adding just a few words validates their work, and more practically, it also clarifies that the criticisms are exhaustive.
  - tedmiston 10y ago
    The structure of what I had in mind was going through a laundry list of aspects of code (functionality, style, structure, functional decomposition, algorithmic efficiency, test coverage, use of libraries, blah blah blah), and making specific positive comments about the things that are already good. Personally I don't glean much value from that i.e., the compliments aren't something I'm concerned with and the feedback isn't something I can act on anyway.
    - gertef 10y ago
      OTOH, by going through that laundry list, it shows that you actually performed a full review. You can optimize that (for example, by having a checklist where you mark off all areas with either constructive criticisms or a checkmark.
- ravicious 10y ago
  >> When giving feedback, some people say that they are brutally honest > As someone who prefers giving and receiving terse feedback... I would suggest that there's nothing wrong with brutal honesty for type of people who appreciate receiving it. It seems to me that you cited the fragment of donw's comment about "brutally honest", but ineffective feedback ("The module you wrote is crap because your code sucks and is hard to maintain.") and then started arguing that some people like receiving terse feedback. But won't you agree that the example of "brutally honest" feedback wasn't in any way terse and that "brutally honest" doesn't necessarily mean terse? I find the second part of the "kind" feedback much more terse: "Breaking those big methods and classes into smaller separate objects and functions would help a lot".

by donw 10y ago

tedmiston 10y ago

> When giving feedback, some people say that they are brutally honest As someone who prefers giving and receiving terse feedback... I would suggest that there's nothing wrong with brutal honesty for type of people who appreciate receiving it. If I write code and forget to test some specific cases, I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version. I don't need to hear compliments on what's right... just what can be improved. Some people really value bluntness and see directness as more friendly because it's honest.

donw 10y ago
Terse feedback can be fine, once you know that, for a specific person, terse feedback is effective. I have met more than a few people that said they preferred "brutal honesty", but would still react very defensively to straightforward, terse feedback. Being terse without seeming to be on the attack is very difficult, and it is human nature to defend ourselves -- and stop listening! -- if we perceive that we are being attacked.
wpietri 10y ago
> I don't need to hear compliments on what's right... just what can be improved. I used to say the same thing, but now I think I was wrong. I didn't want to hear compliments on what's right. But I did need it. Focusing on negatives helped me reduce error rates. But ignoring the positives limited my ability to grow. What got me to slowly switch was learning about appreciative inquiry. It's a practice of focusing strongly on the good aspects of something and seeking to amplify them. I looked into it because a team I was working with had these brutally negative retrospectives. They were in a rut of flagellating themselves every week about all their failures. They were a great team, but weren't performing well because they became gradually more stressed and discouraged. And after I saw that in them, I eventually saw it in myself, too. I'm now 6 or 7 years into consciously switching approaches and I'd never go back. Just today I was pairing with a younger programmer, and we even took some time to appreciate their anxiety. That fear of failing was causing them a lot of problems, but instead of asking them not to worry, I asked them to channel their anxiety into areas where it was useful, like writing good tests. That said, I'm with you on not wanting "nice" versions of things, which I see as a social performance, and not actual kindness.
TeMPOraL 10y ago
> for type of people who appreciate receiving it This is key. I wonder though, what's a good way to signal that to friends and coworkers? I personally declare Crocker's rules[0], but I rarely have the opportunity to communicate that to people I'm talking to. [0] - https://wiki.lesswrong.com/wiki/Crocker's_rules https://wiki.lesswrong.com/wiki/Crocker's_rules "By declaring commitment to Crocker's rules, one authorizes other debaters to optimize their messages for information, even when this entails that emotional feelings will be disregarded. This means that you have accepted full responsibility for the operation of your own mind, so that if you're offended, it's your own fault. The underlying assumption is that rudeness is sometimes necessary for effective conveyance of information, if only to signal a lack of patience or tolerance: after all, knowing whether the speaker is becoming angry or despondent is useful rational evidence. Two people using Crocker's Rules should be able to communicate all relevant information in the minimum amount of time, without paraphrasing or social formatting. Thus, one who has committed to these rules largely gives up the right to complain about emotional provocation, "flaming", "trolling", "abuse" (hopelessly subjective terms) and other alleged violations of etiquette. They give these rights up in the interest of effective debate."
- gbog 10y ago
  I don't think being blunt is more efficient. First, adding a few "kind" softener words do not really take so much time, don't you think so? Second, efficiency in human to human communication is not only a function of raw information density. Adding well chosen "kind words" may allow the reader to get some context and a better understanding of the message. A simple example: say you already communicated with the guy in the past. If you add a reference to this previous communication, the reader will remember you better and adjust the frame. There's so many things passing through language, many are very volatile but still important. We're not computers. Human language have very little in common with computer languages.
  - TeMPOraL 10y ago
    I think it's already captured in Crocker's rules definition - "one authorizes other debaters to optimize their messages for information, even when this entails that emotional feelings will be disregarded". It's not about being rude for the sake of being rude - if a kind word provides some context best, a kind word should be used. The idea here is to free your interlocutor from having to constantly censor their communication in order not to accidentally offend you.
morgante 10y ago
I think one of the important takeaways from the talk is that even if people say they want brutal feedback they probably don't. More importantly, feedback can be totally honest without compromising it's optimism. > I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version I agree that niceness isn't always necessary. Fortunately, that's not what the talk is about. For me, the examples you gave actually fulfills all the criteria for optimistic criticism: - It's impersonal: the focus is on what the code is missing, not your ability as a coder. - It's specific: there are hyper-specific criticism. - It's temporary: the tests are merely "missing" and that's a condition that can be quickly changed.
- tedmiston 10y ago
  This is a totally valid point about my example. Unfortunately for the sake of my argument, it was done by accident (or subconscious). I have been practicing detaching critical feedback from the person and instead attaching it onto the situation or context for quite a while now. In any form, I think that point is crucial.
aninhumer 10y ago
>I would much rather get a code review of "Missing tests for negative numbers, empty string, null" than a longwinded and "nice" version. Could you give an example of what you're imagining a longwinded nice version would be like? Because this seems mostly fine, just a bit clipped. All I'd really expect to improve it is something like: "This is mostly fine. It just needs tests for negative numbers, empty strings and null." Adding just a few words validates their work, and more practically, it also clarifies that the criticisms are exhaustive.
- tedmiston 10y ago
  The structure of what I had in mind was going through a laundry list of aspects of code (functionality, style, structure, functional decomposition, algorithmic efficiency, test coverage, use of libraries, blah blah blah), and making specific positive comments about the things that are already good. Personally I don't glean much value from that i.e., the compliments aren't something I'm concerned with and the feedback isn't something I can act on anyway.
  - gertef 10y ago
    OTOH, by going through that laundry list, it shows that you actually performed a full review. You can optimize that (for example, by having a checklist where you mark off all areas with either constructive criticisms or a checkmark.
ravicious 10y ago
>> When giving feedback, some people say that they are brutally honest > As someone who prefers giving and receiving terse feedback... I would suggest that there's nothing wrong with brutal honesty for type of people who appreciate receiving it. It seems to me that you cited the fragment of donw's comment about "brutally honest", but ineffective feedback ("The module you wrote is crap because your code sucks and is hard to maintain.") and then started arguing that some people like receiving terse feedback. But won't you agree that the example of "brutally honest" feedback wasn't in any way terse and that "brutally honest" doesn't necessarily mean terse? I find the second part of the "kind" feedback much more terse: "Breaking those big methods and classes into smaller separate objects and functions would help a lot".