How would you handle a conversation with someone who thinks "respecting an opinion" means "agreeing with it"?

Sloan the DEV Moderator - Jan 22 '20 - - Dev Community

This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment.

This isn't meant to sound like some scenario-based interview question, though perhaps it would make a good one 😄

I want to share an experience I had earlier in 2019, and ask how you would have handled it: my approach did not go so well.

All of this happened via textual communication, so even though I'm redacting some of the details, I can still present an accurate reenactment of how it went.


Earlier this year, a more senior dev on my team gave me some feedback on a code review, and the short conversation went something like this:

Dev: uses Github's "suggestion" feature to suggest a code change that uses FunctionB instead of FunctionA

Me: That's not necessary here, because X and Y (link to language specification)

Dev: No, even if X and Y, we should avoid using FunctionA. I know the spec, but have a strong opinion on this. Please always use FunctionB, and never FunctionA: it is a well-known anti-pattern to use FunctionA.

Me: I've researched this further, and still don't agree: the anti-pattern opinion seems to come from a lack of understanding of our tools, not from any problem with this particular tool.
FunctionA seems to be best when F and G.
FunctionB seems to be best when X and Y.
Since X and Y are true, and there are no technical downsides of FunctionB over FunctionA, I prefer to use FunctionB here because it fits the situation better and communicates the situation more clearly.

Dev: Thanks for your perspective. I have more to say, but I think we're getting into the philosophy of tool use and this PR is not the right place for that. Let's agree to disagree, but please use my suggestion in this case anyways because it is a convention of this project.

Other Dev enters conversation: If it's a convention, we should look into using a tool that helps us enforce it.

Other Dev: I'd also like to point out that if the language implementation ever changes, Y might not hold true anymore, and could cause FunctionA to give unexpected results, but FunctionB would be unaffected. But it doesn't matter too much in this case.

Me: Okay, let's agree to disagree! Maybe my opinion will change as I learn more. I'll change this to FunctionB since it solves the technical problem just as well and better aligns with our team practices.

Me: That's a fair point, Other Dev, but that situation is unlikely, and if it happened I would expect us to make larger changes to the project to compensate, to avoid breaking uses of this tool.

I thought we handled that situation well by presenting our thoughts to each other and coming to a resolution quickly even though we still were not in agreement by the end. Indeed, later on we had a longer discussion elsewhere in which we each learned a thing or two. It was great 😄

I brought this up in a retrospective with my manager as an example of a positive part of the sprint, but my manager surprised me by saying something like,

This sounds to me like you didn't respect Dev and Other Dev if you still were not in agreement by the end.

I asked for clarification:

I'm not sure I understand you: do you think that respecting someone means you have to agree with them?

My manager responded:

I meant "respect" in terms of the group opinion. The fact that Other Dev supported Dev's suggestion, and both of them have more experience than you, should have been enough to convince you that the suggested path was the right one, and the disagreement should have been resolved.

This seemed like flawed reasoning to me, and I said so.

I listened to their opinions respectfully and presented my own, and in the end we came to a quick resolution despite disagreeing. I recognize that experience and popular adoption can give more weight to an opinion, but that doesn't make it right or appropriate to every situation, and there are a lot of reasons I still might not agree even if it was. I said as much in the discussion: "Maybe my opinion will change as I learn more."

My manager responded:

Would someone else please explain this to Me?

No one did, the topic was dropped, life moved on, and it didn't seem to cause any lasting tension in our working relationship.

But I still don't understand what I could have done differently to yield a more positive outcome. What do you think?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player