Feedback is key to ensuring you're making progress towards a goal. Without it, you're essentially shooting blindly at a target. Maybe you'll get lucky and hit it, but there's a good chance your form could be improved.
It's easy to take the feedback you receive personally – especially negative feedback – but it's important to try to take the feedback you receive as a learning opportunity instead. Giving and receiving feedback is a skill, and with any skill, you need to practice to get better. Below you'll find tips to help deliver feedback in a more effective manner to help prevent a negative reaction, and also some tips for becoming better at receiving feedback.
Ask permission before providing feedback.
A simple "Hey, can I provide some feedback?" can go a long way. Whether you're delivering positive or negative feedback, you set the stage for what's to happen. If someone's already having a bad day, respect their wish to delay the feedback delivery until a later time.
Be timely with your feedback.
Feedback should be delivered within 24-48 hours. The longer you wait, the less likely you are to remember the specific events that occurred, and the more likely the person on the receiving end will also misremember and refute your feedback.
Frame your feedback in a future-forward manner.
We can't change what happened in the past. When you frame feedback towards something that already happened, people are much more likely to get defensive. Here's an example:
"You were late with this deadline. This caused our project to go off track."
"When you miss a deadline, we aren't able to complete projects on time."
You're still providing the same feedback (don't miss your deadlines), but the framing will change the way the feedback is received.
Drop the feedback sandwich and get right to the point.
The feedback sandwich has been a discussion for ages, following a guide of "positive-negative-positive" feedback. Don't sugar coat your feedback. If you need to provide negative feedback, just do it.
Don't forget to recognize accomplishments.
It's much easier to recognize wrongdoing. You're more likely to have an emotional reaction to a negative event vs. a positive event. Don't forget to recognize the good work delivered by your team as well.
Keep your emotions in check.
It's easy to jump on a negative emotion and immediately provide negative feedback. If you're angry, hold off on delivering feedback until you can discuss the situation in a level-headed manner. No good feedback comes from a moment of anger.
Be open to receiving feedback.
This is both the most important and most easily forgotten part. Whether you're a junior developer or you're the team lead, you should make yourself open to receiving feedback from those above, below, and at your level. Others will always have a different view of the work you're doing, and there's always going to be room for improvement.
Keep your emotions in check.
Just as it's important on the delivery, your emotions are important on the receiving end as well. Receiving any form of negative feedback is never easy, so it's easy to jump to getting defensive. Take the feedback, think about it, and then reply if you'd like to clear the air.
Understand the message.
Make sure you're fully understanding what is being said to you, especially before you respond. It's completely fine to ask for clarification if something is unclear.
When asking for feedback, be explicit in the type of feedback you want.
Whether you're looking for suggestions on how to clean up your code, how to best convey a message on a website, or just looking for feedback on a very specific section of your app, be as clear as possible in your request. This will lessen the likelihood of somebody commenting on something entirely unrelated. (And if someone ignores your recommendation and comments on something unrelated anyway, don't take it to heart.)
Both giving and receiving feedback effectively takes time and practice. You're not going to get it right on your first go, and that's totally okay. The more you practice, the better you will become.
One of the most consolidated misconceptions about programming, since the early days, is the idea that such activity is purely technical, completely exact in nature, like Math and Physics. Computation is exact, but programming is not.