mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
20fca17417
sources/tech/20200814 7 tips for giving and receiving better feedback.md
136 lines
7.6 KiB
Markdown
136 lines
7.6 KiB
Markdown
[#]: collector: (lujun9972)
|
||
[#]: translator: ( )
|
||
[#]: reviewer: ( )
|
||
[#]: publisher: ( )
|
||
[#]: url: ( )
|
||
[#]: subject: (7 tips for giving and receiving better feedback)
|
||
[#]: via: (https://opensource.com/article/20/8/better-feedback)
|
||
[#]: author: (Dawn Parzych https://opensource.com/users/dawnparzych)
|
||
|
||
7 tips for giving and receiving better feedback
|
||
======
|
||
Good feedback is important for growing, learning, and improving.
|
||
![Pair programming][1]
|
||
|
||
Getting feedback isn't always easy to handle, but we need to hear it to grow and learn. Feedback can take many forms—from formalized feedback in performance reviews to more informal feedback such as:
|
||
|
||
* Code reviews
|
||
* Peer reviews of writing
|
||
* Comments for a speaker
|
||
* Recommending revisions to a resume
|
||
|
||
|
||
|
||
There is an art to giving, asking for, and receiving feedback in a way that is actionable and helps people improve. To narrow down this topic, I'll focus on feedback related to writing (as that is one of my specialties), but many of these lessons apply to any type of feedback you need to give or receive.
|
||
|
||
### Tips for giving feedback
|
||
|
||
If you've been asked to give feedback, first, confirm you understand what type of feedback is being requested. The person asking for feedback should provide guidelines for what you should focus on. If you don't know what type of feedback to give, ask. Also, make sure to ask when they need the feedback. If you can't meet their deadline, let them know. Maybe the timeline is flexible. If not, they have the opportunity to find somebody else to help.
|
||
|
||
It's OK to say no—a short message declining the request and explaining why is much better than ignoring it and potentially making the person miss their deadline.
|
||
|
||
#### Content vs. style
|
||
|
||
There are many different ways to write a sentence, and everybody has their own style. Focus on the content of what was said rather than how it was said. Unless you've been explicitly asked to help rewrite an article, don't worry if you would have said something differently. If the correct meaning is conveyed, that is what matters.
|
||
|
||
For example, these sentences all say roughly the same thing.
|
||
|
||
> A large part of building and operating software is learning what works and what doesn't.
|
||
>
|
||
> Software engineers spend a great deal of time determining what works and what does not work when building and operating software.
|
||
>
|
||
> Software engineers expend a considerable amount of time ascertaining the effectiveness and interoperability of software and hardware.
|
||
|
||
The "right" version has everything to do with the writer's and the audience's preferred style.
|
||
|
||
#### Clarity
|
||
|
||
This doesn't mean you shouldn't be concerned about clarity. If something is unclear, speak up. It helps when you provide context about why you found something confusing or vague (again, clarity matters). The writer might not know where you are getting hung up.
|
||
|
||
This is unclear feedback:
|
||
|
||
* "This is confusing."
|
||
* "What do you mean here?"
|
||
|
||
|
||
|
||
Better feedback (this is all real feedback I've either given or received recently):
|
||
|
||
* "I think this could use a little clarification on what you mean by 'we.'"
|
||
* "Do you mean a team with a single project, or do you mean to choose a single team?"
|
||
|
||
|
||
|
||
If you have time and it's possible, provide suggestions on how it can be made clearer for you, such as:
|
||
|
||
* "On a hasty reading, I initially misinterpreted this as claiming x (whereas obviously, you meant the opposite)."
|
||
|
||
|
||
|
||
#### Twice as nice
|
||
|
||
Read the entire content at least twice. The first time you read it, don't leave any comments or make any suggestions; just read to see what information is covered. Otherwise, you might suggest that a specific topic should be included—then see it two paragraphs later.
|
||
|
||
#### Leave positive feedback
|
||
|
||
Often when we give feedback, we focus only on the areas that need improvement. If there is something you like, share that feedback as well. Writers want to know what resonates, as well as what didn't quite hit the mark. What made you laugh or cringe? What did you learn?
|
||
|
||
### Tips for getting feedback
|
||
|
||
A great way to receive feedback is by asking for it. Here are some suggestions that will help you get feedback that's most useful to you.
|
||
|
||
#### Be specific
|
||
|
||
When you request feedback, tell your reviewers exactly what you are looking for, including what specific areas you want people to focus on and what not to worry about.
|
||
|
||
This request is vague:
|
||
|
||
> "Can you please read this and let me know what you think?"
|
||
|
||
The reviewer doesn't know if you're asking them to review for technical accuracy, grammar, or something else. I sometimes forget to do this when I ask for feedback, and thankfully, I have a colleague who will follow-up and ask for more context by asking, "What level and depth of review are you looking for?"
|
||
|
||
Since I'm trying to get better at giving specifics when asking for feedback, I often leave comments in my articles for my reviewers with questions I have, things I'm struggling with, or areas I think are weak and need improvement.
|
||
|
||
Here's a good example from one of my colleagues on asking for specific feedback:
|
||
|
||
> "I'd hugely appreciate any comments on this, especially things I have wrong, or over/understate, or other things to include (some of which may be punted to the next version, but hearing them now would still be very useful)."
|
||
|
||
#### State your deadline
|
||
|
||
Make sure to include a timeframe when you need their feedback. You don't want review cycles dragging on and blocking your progress while you're waiting for feedback. Give reasonable deadlines, and if there is a need for urgency, explain why. You might say:
|
||
|
||
> "Can you review this for technical accuracy and readability by the end of the week? Don't worry about grammar. I'll make those edits later."
|
||
|
||
Or
|
||
|
||
> "Can you provide copy-editing by the end of the day? This needs to be published tomorrow to coincide with our launch."
|
||
|
||
#### Decide what to include
|
||
|
||
You may not agree with all the feedback you hear. It is up to you as the writer whether to incorporate it or not. I highly encourage you to incorporate feedback that points out blatant errors. The feedback that can be more challenging is differences of opinion, stylistic changes, etc. I often schedule meetings to review the feedback if there are differing viewpoints. Talking can often clarify things faster than writing comments back and forth.
|
||
|
||
### Conclusion
|
||
|
||
Asking for feedback can trigger [imposter syndrome][2]. That won't necessarily go away, but giving good feedback (even if it is negative feedback) can help a writer overcome that feeling.
|
||
|
||
If you're interested in ways to become a better writer, I've previously written about my [writing process][3], which includes multiple feedback loops.
|
||
|
||
As a writer, your job is to write content that people enjoy, resonates with your readers, and serves a purpose. As a reviewer, your job is to share what you learned and what was confusing. These tips can help you give and receive better feedback.
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/20/8/better-feedback
|
||
|
||
作者:[Dawn Parzych][a]
|
||
选题:[lujun9972][b]
|
||
译者:[译者ID](https://github.com/译者ID)
|
||
校对:[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://opensource.com/users/dawnparzych
|
||
[b]: https://github.com/lujun9972
|
||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/collab-team-pair-programming-code-keyboard.png?itok=kBeRTFL1 (Pair programming)
|
||
[2]: https://opensource.com/article/19/11/my-first-open-source-contribution-impostor-syndrome
|
||
[3]: https://opensource.com/article/20/5/write-about-open-source-software
|