4 ms·

I used to handle this just like you (just shutting up and making the change). There's no specific technique I can give you other than to question your own assum

I used to handle this just like you (just shutting up and making the change). There's no specific technique I can give you other than to question your own assumptions. The problem is that this makes you look like you don't know what you're doing even if you DO know what you're doing, and it prevents either of you from arriving at a better solution that might have been revealed with debate and discussion. Unfortunately, on some teams, a strict hierarchy is imposed and you ARE expected to comply with a peer's instruction in all cases, and they might be closed-minded and unwilling to listen. In this case, just shutting up and making the change is the only option. It's very easy to find this out by just asking your manager if you are allowed to push back or not. If this is the case, one thing that helps is to bring them in to give feedback early on - not waiting until you submit your pull request. But if this is NOT the case, then you should reconsider your approach. > they don't bring any benefits or harm over one another That sometimes is the case, but sometimes not. Having cleaner, more consistent, more conventional, or more performant code are all benefits (obviously). But having to spend time rewriting tested & working code is, in fact, a harm. This harm may be outweighed by benefits of a particular change, but it is non-zero. This is something any senior developer on a mission critical project should know. > trying to convince the other person is a more effortful job Why do you think it's your job to convince them you're right? Does it have to involve anything more than stating your case, simply and politely? If you still can't agree, and the issue is too important to let go, why not ask your supervisor or ask for a tie breaker from a third dev? > and also alters the relationship with that person for bad. This is only true if the discussion devolves into personal attacks, like insulting and name-calling. As long as you avoid doing that, pushing back will probably increase the person's respect for you, even if they don't like it. Respect is orthogonal to congeniality; a person might respect you without liking you, and like you without respecting you. Which kind of relationship would you rather have on your team?

JohnFen 7y ago
> The problem is that this makes you look like you don't know what you're doing even if you DO know what you're doing I haven't had this experience at all. In my experience, everyone on a well-functioning team has a good handle on what the skill level of everyone else on the team, and things like this don't alter that. It's a different kettle of fish if the team isn't well-functioning, of course.
- tboyd47 7y ago
  I'm not talking about people mistaking juniors for seniors. I'm talking about when a reviewer lacks the context to understand what your code is trying to accomplish - which happens all the time, even on well-functioning teams. Those situations require you speak up and at least try to clue the person in. And yes - if you automatically fire off any change requested of you, then it does give the impression that you don't know what you're doing or don't care. I'm talking from experience.
  - JohnFen 7y ago
    > I'm talking about when a reviewer lacks the context to understand what your code is trying to accomplish - which happens all the time, even on well-functioning teams. Yes, this is why my approach is to discuss it with the reviewer. > I'm talking from experience. We have very different experiences, then. Fair enough!
yamrzou 7y ago
This is the right answer. Thank you. But I still have a question : > Unfortunately, on some teams, a strict hierarchy is imposed and you ARE expected to comply with a peer's instruction in all cases. Or maybe fortunately? How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy? Say for example, two senior developers disagree on how to structure a piece of code, because each one finds it more readable his way. Now structuring that code would have implications on other dependent pieces, the team using it, and future development. How do tou handle such disagreement when each member has a strong opinion about the issue?
- tboyd47 7y ago
  > How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy? First, is there no hierarchy at all or a hidden one? That's the first thing to find out - you need to know the rules of the game before you can play. > How do you handle such disagreement when each member has a strong opinion about the issue? If you're a dev, I've had luck in such cases asking for a third dev or a supervisor to step in as a tiebreaker. Or you can find out who is the most knowledgeable and experienced person on the team in this one problem domain, and go with their opinion. Disagreements are not necessarily a negative thing, but an inevitability that can become positive or negative depending on how you handle them. If you're a manager, then you set the rules of the game. Just let everyone know what those rules are and make sure they are followed.

JohnFen 7y ago

> The problem is that this makes you look like you don't know what you're doing even if you DO know what you're doing I haven't had this experience at all. In my experience, everyone on a well-functioning team has a good handle on what the skill level of everyone else on the team, and things like this don't alter that. It's a different kettle of fish if the team isn't well-functioning, of course.

tboyd47 7y ago
I'm not talking about people mistaking juniors for seniors. I'm talking about when a reviewer lacks the context to understand what your code is trying to accomplish - which happens all the time, even on well-functioning teams. Those situations require you speak up and at least try to clue the person in. And yes - if you automatically fire off any change requested of you, then it does give the impression that you don't know what you're doing or don't care. I'm talking from experience.
- JohnFen 7y ago
  > I'm talking about when a reviewer lacks the context to understand what your code is trying to accomplish - which happens all the time, even on well-functioning teams. Yes, this is why my approach is to discuss it with the reviewer. > I'm talking from experience. We have very different experiences, then. Fair enough!

yamrzou 7y ago

This is the right answer. Thank you. But I still have a question : > Unfortunately, on some teams, a strict hierarchy is imposed and you ARE expected to comply with a peer's instruction in all cases. Or maybe fortunately? How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy? Say for example, two senior developers disagree on how to structure a piece of code, because each one finds it more readable his way. Now structuring that code would have implications on other dependent pieces, the team using it, and future development. How do tou handle such disagreement when each member has a strong opinion about the issue?

tboyd47 7y ago
> How do you handle weighting benefits when the team is flat, i.e. there is no clear hierarchy? First, is there no hierarchy at all or a hidden one? That's the first thing to find out - you need to know the rules of the game before you can play. > How do you handle such disagreement when each member has a strong opinion about the issue? If you're a dev, I've had luck in such cases asking for a third dev or a supervisor to step in as a tiebreaker. Or you can find out who is the most knowledgeable and experienced person on the team in this one problem domain, and go with their opinion. Disagreements are not necessarily a negative thing, but an inevitability that can become positive or negative depending on how you handle them. If you're a manager, then you set the rules of the game. Just let everyone know what those rules are and make sure they are followed.