DEV Community

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

Sloan the DEV Moderator on January 22, 2020

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 usuall...
Collapse
 
molly profile image
Molly Struve (she/her)

First off, as a less experienced dev, it is your job to question all of us with more experience so I commend you on doing that!

I guess the only way I would have approached the situation a little differently would have been to ask more questions. If two more experienced engineers than yourself share the same opinion that is opposite of yours keep asking why so that you can hopefully better understand where they are coming from. I find it also helps to always remember that everyone wants the same thing, a well functioning code base. The vast majority of people out there aren't trying to write bad code or make bad decisions on purpose, they are doing the best they can with what they know.

Beyond that, there will be times when you will disagree with coworkers and you have to pick your battles in those cases. Usually when it comes to little things like code organization or implementation I let those go. If its something I think would potentially be problematic to the code base in the future I will argue for those. I have always been on teams where people are very receptive to collaboration so I have never had to go up against an "asshole" who won't budge just because. Most the time everyone hears everyone out and we pick a solution.

Notice I said "a solution". You may think you have the best solution but the team may decide to implement another one instead. If that is the case then go with the team and trust that they picked that other solution on its merits. There are a million ways to do things in our industry and hundreds of ways to do them "right" so you always have to be open to those other methods.

That got a little rambly but TL;DR only thing I would have done differently in your case is asked more questions and taken the conversation to in-person immediately after the disagreement started bc PRs are horrible for back and forths a lot of the time. Talking it out I find is better.

Hope that helps! 🤗

Collapse
 
ben profile image
Ben Halpern

+1 on asking questions.

There's definitely a good likelihood that this whole situation is pretty irrational on the superior's behalf, but we can only go so far in our hopes that everyone sees things in a neutral and accurate way.

Asking questions both helps you gain perspective to make the argument you want to make, while also triggering that reciprocation part of the human brain which just wants to be heard before being disagreed with.

Asking questions and letting folks feel abundantly heard leads to better results regardless of who is being reasonable and not reasonable in the situation.

Collapse
 
lampewebdev profile image
Michael "lampe" Lazarski

Asking more often "Why" would have prevented this from happening, instead of going into a ping pong game of "No, you are wrong".

Collapse
 
jrsofty profile image
Jason Reed

I'm glad I am not the only one to actually want feedback from developers with less experience. I actually tell them that if they see something that they think is wrong to speak up. I don't want them to be intimidated by the more experienced devs. I want then to find their voice and learn to express themselves. Also newer devs may have learned something new that I haven't and it's a chance for me to learn something too.

Collapse
 
seveneye profile image
seveneye

the funny thing is asking more questions also takes experience. Ive seen lots of junior devs who doesn't know what to ask, so I ask for them instead, even if I'm the one lecturing lol.

Collapse
 
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

I definitely would not have said this:

the anti-pattern opinion seems to come from a lack of understanding of our tools

It's 100% okay to disagree, but it also matters how you disagree. Saying something like that undermines a more senior dev's experience by claiming they lack an understanding of the tools they've been working with.

Collapse
 
daniel13rady profile image
Daniel Brady

Yeah I think this might come across poorly 🤔 So how would you claim that a more senior dev's understanding of their tools has a gap, without making them feel undermined? (Not assuming the OP is right or wrong here, just brainstorming better ways for them to voice that feedback)

Collapse
 
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

I don't really think this constitutes an anti-pattern in our case because XYZ.

Basically, I'd say exactly what OP was thinking, but without implying that the senior dev misunderstands the tools they work with.

Collapse
 
daniel13rady profile image
Daniel Brady

The "asking why" approach that others are suggesting might be good here. So instead of just stating their opinion is misguided, maybe asking Dev leading questions based on your own understanding to encourage deeper thoughts from everyone, and see if they come to the same conclusion as you.

I think any dev worth their salt should be eager to revise an opinion in the face of better understanding, but also able to articulate their position effectively to more junior devs so they can learn from you.

Collapse
 
leob profile image
leob

100% agree, it's all about the way you communicate something. Saying "a lack of understanding" is negative phrasing, that's something to be avoided.

Collapse
 
lampewebdev profile image
Michael "lampe" Lazarski • Edited

Just some random thoughts:

  • Discussing something like that in a PR is not good.

  • Even if you are right. Does this small fight win you the war? If functionB is already used in the code base and it works and the team decided to use it. Why fight over it in this one small fight? I would suggest you next time to lose this fight and create a PR that will change the complete code base to functionA if it is that better.

  • Don't underestimate familiarity and easy to use tools. Maybe they were using functionA in the past and it was not good. Instead of directly replying that you are right a better way would have been to ask why he/she thinks so.

  • Sentences like "I prefer to use FunctionB here because it fits the situation better and communicates the situation more clearly." are not the best way to communicate. Why? See the code base needs to be readable and understandable to the team not only to you. What if you write the most performant code in a way that nobody understands it?

  • please use my suggestion in this case anyways because it is a convention of this project. At this moment the team is more important. I'm not saying to not question conventions but a PR is the wrong place.

  • The point about what if the language changes from the other dev is kind of strange. 🤷‍♀️

  • A Manager in a retro? Like a team lead? Why is a manager in a team retro? 🤷‍♀️

  • I don't really know what to say to the discussion with the manger. Is this copy and pasted or what you remember?

In general changing someones mind by saying his wrong will not change his mind. The only thing that will happen is that he/she will close her mind and be in defense. I would suggest you to ask more "Why?" "Why do you think so?" "Why is this better?" "Why..." or "Can you explain me in your own words...".

Collapse
 
matttyler profile image
Matt Tyler

I think what you did is a good example of one of the Amazon Leadership Principles - Disagree and Commit

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

amazon.jobs/en/principles

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

I can't really add much on top of Molly's excellent comment, but I do want to say this: your manager is incorrect, and any project or workplace which equates "respect" with "being a yes-man" is not a healthy environment.

This sounds like a pattern I've seen all too often, although I'd withhold labeling it as this until you can actually point to multiple instances:

  1. Dev could be, to some extent or other, known on the team to have fragile feelings, and to react in defensive/hostile/toxic ways. This can be unintentional, perhaps a person never learning social skills, or intentional, as a way of seizing control of a project, team, or company. (I've been witness to two premeditated coups like this.)

  2. The Manager has come to consider Dev "irreplaceable", probably because of his/her technical knowledge or skill.

  3. In order to keep Dev at the company, then, Manager must use the full powers of their position to protect Dev's feelings above all else. This means Manager has to always take Dev's side.

  4. However, because #3 an inherently irrational action to take, Manager must justify it to himself/herself by equating "disagreement" with "disrespect"; because Dev has seniority, Manager can then believe that he/she is just enforcing respect of seniority, instead of what's actually going on.

  5. Reversal of authority achieved: Dev needs only complain to get Manager to do what he/she wants.

That may sound like an uncharitable assessment, but I've literally observed that exact pattern more times than I can keep track of. It's unfortunately common, especially in tech. I always handle such a recurring dynamic the same way: (1) address it quietly with the manager, (2) refuse to maintain the status quo in my own actions, and if all else fails (3) resign. The worst thing you can do for everyone, yourself included, is to normalize it.

But again: watch for a recurring pattern of behavior. Communication glitches and collaboration dynamic flaws exist in any team, and that can lead to isolated instances of behavior that looks like the preceding (but isn't). Only if this happens regularly do you need to be wary of such a dynamic as I've described.

Collapse
 
u8nc profile image
MiAn • Edited

Just quietly diarise what you can after his response:

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)

but don't make an assertive statement yet. You should ask " Is that necessary here ... ? "

and when things go pear-shaped down the track, refer to this out as evidence as WillSmart suggests. You will have more experience by this time, not only in code but in office relations.

Your manager needs to bear in mind that in a room of 100 people, 99 people saying X doesn't make it right. It can be that 1 person saying Y that produces a 'turnaround' that matches the buying public's perception of " well this is new" with dollars following.

But only if it is clear that Y is the right answer! Don't become an argumentative trailblazer either.

The close of your final statement is also telling: ".. to yield a more positive outcome". I think you did quite well given the above, including Jason's advice. But "outcome" is probably still in incubation, other dev's prediction might come true but in a change of manager, not language.

Just bide your time quietly.

Collapse
 
leob profile image
leob • Edited

I think you and the other devs (the senior and "the other dev") handled this well by concluding "Let's agree to disagree" and then moving on. The intervention by the manager was totally unnecessary. A manager's job is to facilitate and enable, not to police or to micro-manage, or to belittle juniors vis-a-vis seniors.

And yes, saying (being forced to say) "yes I agree" when in fact you don't is totally wrong, that's what they do in a dictatorship with yes-men and servants, it just ain't right.

Collapse
 
monicat profile image
Monica Macomber

See, I thought the devs' discussion went well too. I'm surprised at all the comments critiquing it 🤷‍♀️

I suppose it could have been more tactful, but tact can get in the way of clarity and clarity's important in a discussion about coding practices.

Collapse
 
madza profile image
Madza

I would gift Him/Her a book "The Power of a Positive No" by William Ury.

Collapse
 
willsmart profile image
willsmart • Edited

IMO your personal view of what is correct, true, best-practice, an anti-pattern, etc.. in programming (as in many other parts of life) should be evidence-based, not to enable a consensus.
Your actions within a company (commits/merges/standards/etc..) should aim to find a quick consensus, but there's no obligation to personally agree with that consensus. There is an obligation to contribute as best you can to making it a good one.

I mean, change your mind because you were wrong, not because you were told to or "everyone else here does it this way". But make your actions within the company swift and social enough to avoid losing it time and money while you choose between two semi-equivalent functions within an unrelated PR.

People disagree for good reasons, there is often no right way, this is fine.

It sounds like you did the right thing (other than possibly being a bit weak with a manager that sounds like they're a bit more used to nice, friendly groupthink. I think you can get a pass for that though.)

The code is better for your input.

Collapse
 
monicat profile image
Monica Macomber • Edited

Doesn't seem that bad to me, I think you handled it well. Your manager may have some "follow orders without question" kind of thinking going on here:

both of them have more experience than you, [that] should have been enough to convince you that the suggested path was the right one

That could have been a better point to let it go. I agree that a senior dev's opinion should carry some weight but I'd disregard his advice to be convinced and stop thinking for yourself, that's a little goofy 🙃 Seniors and juniors can always learn from each other.

You had a honest discussion, listened to the senior dev and agreed to do what he asked even if wasn't your first choice. No problemo.

Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard • Edited

Wow that's bad!

I have some options

  • Ask: Why is this important right now for the project?. Because it's almost never important enough to justify anyone being exhausted by arguing.
  • Have Backbone; Disagree and Commit (stealing this one from Matt Tyler)
  • Try to make everybody read: How to Use a Code Review to Execute Someone’s Soul
  • If nothing works, leave this team or this company
Collapse
 
jwp profile image
John Peters

Get out as soon as possible. It's a toxic environment with huge egos.

Collapse
 
jose31canizar profile image
José Daniel Cañizares

Respect their opinion, without agreeing with it.