I’ve authored over 500 PR's at AWS.

As a jr engineer I hated receiving comments. I didn’t know how to address them with effectiveness.

I improved by cultivating empathic listening. I shipped production code in fewer iterations.

Here’s how I address PR comments.

I understand why peer feedback matters.

My peers have unique technical paradigms. They’re intelligent individuals with a variety of experiences.

Their perspective exposes areas of my code to improve. Their willingness to review shows an investment in my growth.

I read PR comments in monotone.

I imagine they’re talking with a straight face, calm tone and friendly demeanor. This nullifies my instinct to get defensive.

It calibrates my reference frame. They’re helping, not criticizing. (Exception: toxic people.)

I clarify every comment.

Ambiguous or half-baked comments are the enemy. I refuse to “guess” what the reviewer wants. The cost of guessing wrong is a derailment of my time.

I don’t touch the code lines in question until I understand the reviewer’s suggestion.

I take time to understand the *reason why* behind every comment.

This engrains the underlying principle in my brain. It helps me remember the principle in future coding situations.

Even most nitpicks have a justifiable *reason why.* I take them seriously.

I view the feedback through an objective lens.

It doesn’t matter if the reviewer is a newly hired jr, or a staff engineer with 15 years of experience.

Only the truth matters. The comment is either correct, incorrect or debatable.

I express gratitude for correct comments.

It takes diligence to find flaws or ideate a more readable approach. I thank my peers when they do so.

Sometimes one comment applies to many places. I fix the flaw in every applicable place within the PR.

I fix my code even for incorrect comments.

Incorrect comments are indications that my code caused confusion.

I ask myself, "what caused this person to say that?"

I find the root cause of confusion. Most of the time it exposes an opportunity to clarify my code.

I compare the *reasons why* for debatable comments.

I seek first to understand their view. Then for them to understand mine. In that order.

I stand my ground when my *reason why* is stronger. If necessary I bring in a third person to resolve a disagreement.

I avoid sunk cost fallacy.

It doesn’t matter how much time I spent on the first revision. If I did it wrong, I take a flamethrower to my code and fix it.

I double check the comments before submitting a new revision for thoroughness.

The above steps helped me leverage feedback from my teammates to improve and grow. This raised my PR quality over time.

What suggestions do you have for addressing PR feedback?