Giving and Receiving Feedback Is Still Hard

Feedback Scared Me

In my first year, I had my first performance review. "Your learning speed is good, but your time estimates are inaccurate." Objectively true — I'd estimated 3 days for a task that took 8. But that night I couldn't sleep. "Am I someone who can't even estimate properly?" Self-doubt consumed me.

Looking back, it's funny. A first-year developer accurately estimating timelines would actually be weird. But back then, every piece of feedback felt like a judgment on me as a person.

I Learned to Receive First

The problem was my defense mode activating whenever I heard feedback. "Well, the reason for that was..." — I'd jump to justification immediately. I practiced consciously holding that reflex back. Listen first, separate what makes sense from what doesn't, and save questions for later.

I memorized this sentence: "Thanks for the feedback. Could you tell me specifically which situation made you feel that way?" Using this instead of reflexive excuses made conversations far more productive.

(Though honestly, negative feedback still stings. I understand it rationally, but emotions need time to catch up.)

Giving Was Even Harder

In my third year, I had to review junior developers' code and give feedback. I was too blunt at first and it became a problem. When I wrote "this logic is inefficient," the junior started preemptively apologizing on their next PR. "If I did anything wrong again, please let me know." My feedback had intimidated them.

After that, I changed my approach. Start with something positive. "This abstraction is really clean." Then suggest improvements. "This part might work better if you did it this way — what do you think?" End with encouragement. "Overall, this is a lot better than last time."

Some people criticize the feedback sandwich as dishonest. But in my experience, it actually works. The rate at which the junior accepted feedback without going defensive went way up.

Mistake: I Missed the Timing

Once, I noticed a structural problem in a junior's code but I was too busy to give a thorough review, so I let it slide. "I'll mention it next time." That "next time" never came. Two months later, new features had been built on top of that code, and the refactor ended up taking a full week.

Feedback is cheaper the sooner you give it. Giving it before code is merged is 100 times easier than after.

The Subtlety of Peer Feedback

Giving feedback between peers — not in a boss-subordinate dynamic — is even more delicate. When someone at your level says "your code has a problem," it can turn into an ego battle. I've caught myself thinking "you're not perfect either" when receiving feedback from a peer.

Overcoming this requires both sides to recognize it's "feedback about the code, not the person." The framing needs to be "this isn't about you doing something wrong — let's find a way to make this code better together."

Five Years In and It's Still Hard

Honestly, I don't know if there'll ever be a day when giving and receiving feedback feels comfortable. It makes me nervous every time. What has improved compared to before is that I take feedback less personally. Not a perfect score — maybe a 60 out of 100. Still have 40 points to go.