Real PR Replies to My Code Comments

May 28

Reviewing code is a great opportunity to learn from other developers. The PR should be the time where we show our code to others, polished and ready to go.

This hasn’t always been my experience. I’ve frequently seen code that isn’t fit for purpose and I’ve needed to leave 10, 20, or more comments on the code. That isn’t a problem, we can resolve those comments and get the feature into the codebase.

That doesn’t always happen. Sometimes a developer will leave a reply to my comment that might make no sense and honestly crushes my soul as a code reviewer.

Next PR

Me: “The spelling for this is ‘initial’, could we change it please”
Them: “I’ll look at this in my next PR (clicks resolve)

Result: We have a large number of simple misspellings within our codebase.

I can’t see this anywhere else in my module

Me: “You can simplify this by using higher-order functions. [Gives example that could be copy-pasted and used]”
Them: “I can’t see this style anywhere else in my module”

Translation: “The code works, why change it?”

Result: We often make code decisions because of the way code is, rather than what it could be. Things never improve.

It’s tested

Me: “Is this tested?”
Them: “It’s tested.” (clicks resolve).

Translation: “It looks good to me, what is your problem? I don’t want to write tests.”

Result: It’s never actually tested.

I’ll look into it (click resolve)

Me: “This violates DRY (don’t repeat yourself). Extract these lines (34–44) into a reusable function and call it from there.”
Them: “I’ll look into it.” (clicks resolve)

Translation: “I’m not going to do anything about this, but I want you to stop bothering me.”

Result: Nothing gets improved.

The Nonchalant Naysayer

Me: “This function is redundant. Why is it here?”
Them: “It’s fine, we don’t know what this does. Let’s just leave it.” (adds comment to the function)

Translation: “Who needs clean code”

Result: We have redundant code.

The Ghost

Me: “Can we refactor this to follow our coding standards?”
Them: Silence.

Translation: “We have coding standards?”

Result: The PR lingers. You poke them again. Nothing. Eventually, you either give up or do it yourself. The ghosting is real.

The Know-It-All

Me: “This could be optimized by changing X to Y.”
Them: “Actually, in my experience, doing Z is better.”

Translation: “I think I’m better than you”

Result: Proceeds to do nothing. Because apparently, “experience” outweighs logic and performance improvements.

The Revisionist

Me: “This approach seems inefficient. Any reason for this method?”
Them: “We discussed this last sprint, and it was agreed upon.”

Translation: “I’m too lazy to explain, and we probably didn’t agree on anything, but it sounds authoritative.”

Result: A messed-up codebase.

The Deflector

Me: “This variable naming is unclear.”
Them: “Good point can you check the rest of the file for similar issues?”

Translation: “I can stop you from blocking my PR if I make it as difficult as possible for you to leave comments for me.”

Result: Deflection at its finest. Now it’s your job to review not just the PR but the entire codebase. Well played.

The Oblivious

Me: “You didn’t address the feedback from the last review.”
Them: “Oh, I didn’t see that. I’ll get to it.”

Translation: “I thought you’d forgotten about this.

Result: They won’t get to it. Ever.

Conclusion

And thus, my dear readers, PR reviews remain a battlefield where efficiency, logic, and common sense go to die. But we march on because, in the end, someone has to ship the damn product.

The Secret Developer