A while ago I asked help in communicating Frameworks 5 and our releases. I'd like to acknowledge the awesomeness of Howard Chan who stepped forward to first write an article about our evolving release plans and now help publish an overview of what Frameworks 5 brings to Qt developers all around the world.
Howard is 15 and active in the Kubuntu community too. He is also participant in the season of KDE - a typical KDE contributor who's all over the place, if you ask me. And has already stopped listening to my suggestions and has figured out what he wants to write next ;-)
You're my hero, Howard! Great work and I'm glad you plan on sticking around.
25 September, 2013
20 September, 2013
Giving constructive feedback
Feedback is often equated to 'yelling'. But it doesn't have to be - feedback is, after all, central to learning. And in Free Software, where learning is a major motivation for many participants, proper feedback is very important.
Many of you have seen how Linus can yell at people and unfortunately, some mistake that for effective communication. It is not. But what DOES constitute effective feedback?
And have the right attitude towards whatever has to change: everybody makes mistakes. Constructive feedback should be building up, not breaking down. None of us is born as a super coder, we all had to learn. If you and/or the other person are angry, it will be a shouting match. If there is no way for the other person to improve, why frustrate him or her with feedback?
The time element is crucial as well. Feedback should be timely: giving feedback on an event that took place weeks ago, most likely long forgotten by the subject, offers little value. Be sure you have a certain event or action in mind and can be specific about when, where, who was involved and what the results were.
To focus on behavior use adverbs to describe action, rather than adjectives describing qualities. Help the other person understand the impact their actions have.
Let me give some examples:
This also works with compliments:
Negative feedback which is too vague just frustrates: there is nothing to improve. But unspecific positive feedback is not that great either: people frequently doubt your motives ("Is she trying to get something from me?") and it even makes some people feel insecure.
Note that when giving feedback, people have a tendency to emphasize or even exaggerate. Feedback tends to land much harder than you think, even with people who seem impervious to criticism. It's better to bring it softly and remind people later then to lay it on heavy and make them feel inadequate or not appreciated.
It matters how you introduce the feedback. If you weren't asked for it, note clearly that you'd like to give some feedback. Perhaps this is a bad time - allow the other to point that out and if so, just let it go.
Then, seek for balance. Certainly there are things to improve, but there is always something that was done well. We tend to focus on the negative. To prevent that, 'sandwich' the negative part with positive feedback: start with something that went well, follow with the part that needs improvement, finish with another part that went well or a silver lining. Not only does this help digest the feedback better, it tends to force you to think about it more as well.
If you can, try to give some tips or hints on how to improve. Share how you dealt with this issue in the past, perhaps. Here, too, be as concrete as you can.
After giving the feedback, let the other talk. It is not unlikely that the recipient will act defensive. Don't take that as meaning the message did not land - most people have trouble admitting mistakes when confronted with them, even if they are brought the Right Way™. Let them respond, say you understand - most importantly, don't pile up more 'evidence'. You've done what you can, it is now their responsibility to take it - or not. If you get no response you might want to ask a open question like: "What do you think".
Note that you can give too much feedback. Improving oneself is a lot of hard work - and one can work only on so many things at once! Recognize progress, even when it is slow, and leave room for mistakes. If a colleague tends to make certain typical mistakes you don't always have to point them out. Give him or her time and opportunity to self-correct, silently accept some of the mistakes and space out the feedback a little.
Giving and taking constructive feedback is a hugely useful skill to have - it helps you as well as others to learn and get better. And while most of our communication takes place online, these rules apply as much if not more so. Thanking somebody for a patch, starting by commenting on the good side of it, before you hack and slash in on the less-than-great parts, adding concrete ideas for improvements, and finishing with a high-note in proper sandwich style: it can make the difference between getting an improved patch or never hearing from the contributor again.
If you have comments, feel free to share them ;-)
Many of you have seen how Linus can yell at people and unfortunately, some mistake that for effective communication. It is not. But what DOES constitute effective feedback?
Three Rules
Plenty of books have been written on the subject. To save you the reading effort, I'll summarize the most important lessons here: three rules for how to give constructive feedback.RULE 1: find the right time and place (or don't do it at all)
Both you and the other person should be in the right place, mentally and physically, for the feedback. For example, don't embarrass a person in front of a crowd. Feedback is best given in private, unless of course it is explicitly asked for in a group. But even then, think about what you say.And have the right attitude towards whatever has to change: everybody makes mistakes. Constructive feedback should be building up, not breaking down. None of us is born as a super coder, we all had to learn. If you and/or the other person are angry, it will be a shouting match. If there is no way for the other person to improve, why frustrate him or her with feedback?
The time element is crucial as well. Feedback should be timely: giving feedback on an event that took place weeks ago, most likely long forgotten by the subject, offers little value. Be sure you have a certain event or action in mind and can be specific about when, where, who was involved and what the results were.
Rule 2: Describe, don't judge or infer
Most important, constructive feedback has to focus on the facts of behavior in a concrete case. And on its consequences, not on the person and who they are. That sounds easier than it is. It is best to follow this format when giving feedback:- describe the specific behavior/action/code itself
- describe how it made YOU feel (emotional feedback) or the effect it has on $SUBJECT (technical)
To focus on behavior use adverbs to describe action, rather than adjectives describing qualities. Help the other person understand the impact their actions have.
Let me give some examples:
- unhelpful: "You were really an asshole in the meeting today" -> personal and pretty darn judging
- unhelpful: "You were trying to derail the discussion! -> inferring goals
- helpful: "When you talked so loudly during the discussion you made me feel really anxious"
- unhelpful: "Your patch sucks" -> not concrete
- helpful: "If you write code like $EXAMPLE you will break $DESIRED_BEHAVIOR"
- unhelpful: "You always forget to add comments to the code!" -> generalization
- helpful: "Yesterday when you checked in the code for X, you did not add comments in $FILE, so it took me a while to figure out how it did fit in"
This also works with compliments:
- unhelpful: "You're a great coder!" -> unspecific
- helpful: "When you commented the code with that high level overview you made it easy to understand the flow of the class"
Negative feedback which is too vague just frustrates: there is nothing to improve. But unspecific positive feedback is not that great either: people frequently doubt your motives ("Is she trying to get something from me?") and it even makes some people feel insecure.
Note that when giving feedback, people have a tendency to emphasize or even exaggerate. Feedback tends to land much harder than you think, even with people who seem impervious to criticism. It's better to bring it softly and remind people later then to lay it on heavy and make them feel inadequate or not appreciated.
Rule 3: Sandwich it
It matters how you introduce the feedback. If you weren't asked for it, note clearly that you'd like to give some feedback. Perhaps this is a bad time - allow the other to point that out and if so, just let it go.
Then, seek for balance. Certainly there are things to improve, but there is always something that was done well. We tend to focus on the negative. To prevent that, 'sandwich' the negative part with positive feedback: start with something that went well, follow with the part that needs improvement, finish with another part that went well or a silver lining. Not only does this help digest the feedback better, it tends to force you to think about it more as well.
If you can, try to give some tips or hints on how to improve. Share how you dealt with this issue in the past, perhaps. Here, too, be as concrete as you can.
After giving the feedback, let the other talk. It is not unlikely that the recipient will act defensive. Don't take that as meaning the message did not land - most people have trouble admitting mistakes when confronted with them, even if they are brought the Right Way™. Let them respond, say you understand - most importantly, don't pile up more 'evidence'. You've done what you can, it is now their responsibility to take it - or not. If you get no response you might want to ask a open question like: "What do you think".
Note that you can give too much feedback. Improving oneself is a lot of hard work - and one can work only on so many things at once! Recognize progress, even when it is slow, and leave room for mistakes. If a colleague tends to make certain typical mistakes you don't always have to point them out. Give him or her time and opportunity to self-correct, silently accept some of the mistakes and space out the feedback a little.
Feedback 101
There's something to receiving feedback, too, of course. Note that following the rules above isn't always easy and sometimes people are frustrated and do yell. Try not to get angry - feedback, any kind, can help you improve. Even if it is not brought to you in a nice way.Giving and taking constructive feedback is a hugely useful skill to have - it helps you as well as others to learn and get better. And while most of our communication takes place online, these rules apply as much if not more so. Thanking somebody for a patch, starting by commenting on the good side of it, before you hack and slash in on the less-than-great parts, adding concrete ideas for improvements, and finishing with a high-note in proper sandwich style: it can make the difference between getting an improved patch or never hearing from the contributor again.
If you have comments, feel free to share them ;-)
Subscribe to:
Posts (Atom)