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
FunctionBinstead ofFunctionAMe: 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 useFunctionB, and neverFunctionA: it is a well-known anti-pattern to useFunctionA.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.
FunctionAseems to be best when F and G.
FunctionBseems to be best when X and Y.
Since X and Y are true, and there are no technical downsides ofFunctionBoverFunctionA, I prefer to useFunctionBhere 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
FunctionAto give unexpected results, butFunctionBwould 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
FunctionBsince 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?
Top comments (22)
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! 🤗
+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.
Asking more often "Why" would have prevented this from happening, instead of going into a ping pong game of "No, you are wrong".
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.
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.
I definitely would not have said this:
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.
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)
Basically, I'd say exactly what OP was thinking, but without implying that the senior dev misunderstands the tools they work with.
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.
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.
Just some random thoughts:
Discussing something like that in a
PRis not good.Even if you are right. Does this small fight win you the war? If
functionBis 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 tofunctionAif it is that better.Don't underestimate familiarity and easy to use tools. Maybe they were using
functionAin 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 aPRis 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...".
I think what you did is a good example of one of the Amazon Leadership Principles - Disagree and Commit
amazon.jobs/en/principles
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:
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.)
The Manager has come to consider Dev "irreplaceable", probably because of his/her technical knowledge or skill.
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.
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.
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.
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.
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.
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.
I would gift Him/Her a book "The Power of a Positive No" by William Ury.
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.
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:
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.
Wow that's bad!
I have some options