[HN Gopher] Ask HN: How do you handle conflicts with your peers?
___________________________________________________________________
Ask HN: How do you handle conflicts with your peers?
The question is a generic version of the problem I am facing in my
team. A senior person keeps leaving comments to my diffs which are
at best can be summarized as his preference for doing things. More
than not, I end up making those changes, because as they don't
bring any benefits or harm over one another; trying to convince the
other person is a more effortful job and also alters the
relationship with that person for bad. I am looking for ways how
you handle similar situations and how I can make best out of it.
Author : aryamaan
Score : 36 points
Date : 2020-01-17 13:22 UTC (2 days ago)
| JohnFen wrote:
| If a team member is requesting changes that don't cause any harm,
| then I tend to just make the changes in the interest of overall
| productivity.
|
| If, however, I have a sound technical reason to disagree, then I
| discuss it with them. 90% of the time, a solution can be arrived
| at quickly, with one of us seeing that the other's approach is
| the best one, or both of us finding a third approach.
|
| For the other 10% of the time, I've found that both of us are
| making really solid points. So I rope the rest of the team in on
| the issue, summarize as accurately and fairly as possible what
| the dispute is, and what the position of each of us is (if I
| can't correctly state the other's argument, that means that I
| don't really understand it -- and that has to be corrected
| first). So far, every time I've done this it has led to a rapid
| resolution, often because there's something that both of us
| missed, but someone else in the team noticed.
| gherkinnn wrote:
| > make the changes in the interest of overall productivity
|
| I thoroughly disagree.
|
| If the changes are indeed inconsequential and a matter if
| taste, it is a waste of his time to mention these things and a
| waste of your times to change them.
|
| In general, I very much dislike the "oh well, it's not that
| much effort for me anyway" argument. It's poison and lets wrong
| people reign supreme.
|
| I see no reason to give in to such behaviour.
| Klathmon wrote:
| I was in a situation where that 10% of the time in your example
| was more like 50% of the time, and in my opinion I was the only
| one making valid points.
|
| After months of "losing" discussion after discussion to what I
| felt like was the worse decision, I ultimately made the
| decision to leave.
|
| I still miss many of the other people at that job even a year
| later, and I still think the startup is really on to something
| good, but I couldn't work somewhere that I felt was heading
| down the wrong path at every decision.
|
| For a while I would question if I was wrong to leave or if the
| main person I disagreed with was right on a lot of points, but
| I realized that even on a bad day I'm happier where I am now
| than I ever was at that job.
| bjourne wrote:
| You talk to that person.
| cryptozeus wrote:
| I would go for a walk over coffee or tea and try to understand
| the reason for those comments. Walk and coffee makes it informal
| which shows non conformational approach. Something about walking
| makes it an easy conversation compare to sitting in the room face
| to face with looking at each others expressions.
| omar_a1 wrote:
| So, I have a related question: What do you do when the comments
| aren't being made in good faith?
|
| In other words, incessant, aggressive, and unsolicited, with the
| reviewer not backing down even after you've implemented their
| changes? (e.g. Their previously implimented suggestion now are
| the wrong approach according to their next round of comments.)
|
| I've tried simply going along with it, recognizing my own
| technical inexperience compared to theirs, but end up getting
| nothing done because of the capriciously-set goalposts.
|
| This has been a recurring problem for me. Any tips?
| roenxi wrote:
| The 'perfect scenario' I work on is to try working from inside
| to out. The first question is "Do I understand?" - maybe the
| goalposts aren't shifting and there is something going on that
| you haven't picked up.
|
| Checking that you understand involves finding evidence; so now
| you should have some evidence to go to someone else and ask "Do
| I understand?". They can help review the evidence and provide a
| check that it is convincing or at least realistic.
|
| Having been thorough and made sure that there isn't something
| to fix up on the easy side, the next step is going to the
| reviewer and (gently, slowly but directly) raising concerns
| they are giving unhelpful feedback. An easy trap here is having
| evidence while they are going in blind which is a rather
| threatening imbalance, so give them time (maybe a few days) to
| think before expecting a response or there might be fireworks.
|
| That exhausts the social work, so if the situation is still
| unresolved consider if it is reasonable to formally escalate
| the evidence to someone somewhere in the command chain so that
| they are aware the reviewer needs some coaching.
|
| That covers everything that can be done short of quitting.
| kqr wrote:
| > More than not, I end up making those changes, because as they
| don't bring any benefits or harm over one another; trying to
| convince the other person is a more effortful job
|
| Does this imply the other person thinks their suggestions bring
| significant benefits? (If not, they are already aware of the
| problem and may just need an explicit reminder.)
|
| If they do (and you are sure they are wrong about it), it sounds
| like they have a miscalibrated sense of what matters -- this
| would show up in all reviews they do, i.e. affect more people
| than you. If it doesn't, it could mean more people have this
| miscalibrated sense.
|
| What I'm saying is that you might have just unearthed a huge
| systemic flaw in your teams review process. The worst thing you
| can do now is ignore it. Make a thorough effort at creating
| agreement within the entire team about what the goal if your peer
| reviews are, and which types of things are important.
| jimmyvalmer wrote:
| Nature of the beast, I'm afraid. The "beast" is group
| programming.
|
| First, there ought to be a firmwide linter and style-checker
| applied to all changesets. This avoids a whole class of reasons
| to quibble.
|
| Second, and this is more controversial, outlaw any "this is how I
| would have done it" remarks, and institute a policy whereby
| quibblers make their proposed edits themselves.
|
| I need to use git as an example since that's all I know.
| Quibblers fetch your PR [following this](
| https://stackoverflow.com/questions/27567846/how-can-i-check...),
| make their changes, and push on another branch, and ask for your
| counter-review.
|
| In the vein of "talk is cheap, show me the code," verbal nitting
| is too easy and hurts morale. Quibblers, if they feel strongly
| enough about their nits, need to make a proper effort to
| "correct" your code themselves.
| ncheek wrote:
| My issue with requiring a so-called "quibbler" to develop the
| proposed change themselves is it puts a high cost on making
| constructive recommendations.
|
| This can be useful for dealing with the type of argumentative
| person who will find something wrong with anything. But for a
| busy person who's been assigned a PR to review, this
| methodology restricts them from offering feedback since they
| don't have time to develop fixes, only to suggest them.
|
| Do you resolve this by ensuring PR reviewers are allocated
| enough time in their schedule to develop suggested changes?
|
| There's another problem here. Requiring others to fix bad code
| instead of pushing back bad PRs to the original developer
| removes an incentive for them to write good code. If someone
| else will fix it, why bother? Do you resolve this at the
| performance review level?
|
| There ought to be some middle ground here, where you can shut
| down actual quibblers while allowing legitimate feedback to be
| quickly given.
| desbo wrote:
| How do you distinguish between "quibbles" and changes that are
| worth making yourself? I suspect it's quite a subjective thing.
|
| I'd also suggest using a less disparaging term than quibblers.
| jimmyvalmer wrote:
| Does it profit anyone to make that distinction? Unless the
| quibble is a genuine nit (spelling error or one-line change),
| have the quibbler implement the desired change. Oftimes the
| quibbler misjudges how much code would have to change to
| accommodate his "minor quibble." Better to have him figure
| that out first-hand, than the original author having to
| convince him herself.
| sjg007 wrote:
| I like this solution. It saves a whole bunch of rework. And it
| forces the person who wants the change (especially after a
| design review was approved)to put up.
| tboyd47 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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?
| jlengrand wrote:
| A few ideas :
|
| * Sit together as a team, agree on 'best practises'. Summarize
| them in a written form and refer back to it. Avoids having the
| same discussions multiple times.
|
| * Try to automate all that can be : For example using an auto
| formatter avoids the 'this method is too long, or the curly
| braces come here discussions'.
|
| * If it is a specific problem with someone, talk about hoew you
| feel about the behaviour, not whether it's right or wrong.
| Explaining how you feel can help the person in front understand
| the facts without having to specifically agree. Feelings are
| irrational by nature.
|
| In the end though : "Arguing with a DEVELOPER is like wrestling
| with a pig in the mud. After a few minutes you realize the pig
| likes it."
| ac2u wrote:
| Where I work:
|
| We encourage people to mark their comments on diffs as to whether
| it should be regarded as a blocker to being merged, or not a
| blocker. (Perhaps poster could ask the Senior to do this)
|
| Blockers should be comments to correct:
|
| - code which goes against either the spirit of the spec or the
| spec itself, in other words, wrong behaviour.
|
| - something which could really harm performance in a meaningful
| way (back this up with benchmarks)
|
| - code which could break something else (probably a sign of a
| missing test elsewhere)
|
| Non blockers should be the subjective things that are the topic
| of OPs post, but it's the responsibility of the reviewer to make
| that clear.
|
| The committer can then decide whether to implement or not.
|
| We couple this with quarterly patterns and practices meetings
| where we can discuss any of the subjective things which come up
| over and over again as points of friction. If we can come to an
| agreement, great, if we can come up with a linter rule to enforce
| the decision automatically, even better. Then it's removed as a
| point of interpersonal friction.
|
| There's a culture I push for in the company I work for and in the
| teams within.
|
| It's to try and best as possible, to check your ego at the door
| and regard the code as 'the companies code' rather than 'your
| code'.
|
| This is important to strive for in your Seniors just as much as
| less-senior developers. (Rank shouldn't be blindly used as
| barometer of the decision whether to hear out feedback or not).
|
| When you keep focus on the culture, working practices start to
| emerge rather than trying to dictate them from the top down.
| simplyinfinity wrote:
| Recently we've come to the same conclusion with my team. With
| one small distinction, we prefix all comments with tags
|
| [nit] : i would do this differently (opinion based) (for vs
| foeach for example )
|
| [tip] : for future reference you can do this in x or y way, or
| you can use foo framework/language feature, but your way is OK
| to
|
| [blocker] : possible bug,performance,security business logic
| issues
|
| [Q(uestion)]: what is the reasoning behind this code ( could
| also indicate need for documentation)
|
| the nit & tip ones we don't force anyone to fix or even
| address, but all questions and blockers must be answered &
| resolved.
| Klathmon wrote:
| I've also adopted almost exactly this in all code review
| comments anywhere.
|
| I try to make my intentions of the comment explicit, saying
| things like "this is a minor nitpick, but..." or "as a tip
| for future changes, this can be done like..."
| Jagat wrote:
| If the comments are non-blocking, I usually accept the diff and
| leave it to the submitter to do as they please with the review
| comments.
| gherkinnn wrote:
| A few things:
|
| - Many stylistic choices can be handled with linters, formatters,
| styleguides and the like.
|
| - Some append a _nit:_ (nitpick) to the comment: "Do with these
| changes as you please".
|
| - Picking on trivial stuff is akin to bike shedding. It takes
| little to form an opinion on the trivial while the difficult
| parts are often ignored.
|
| - Simply point out that this is a non consequential thing.
|
| - Define a CR manual for your team/group/company/whatever. Talk
| about what should be done, what ought to be ignored. An open
| discussion often sheds light on people's motivations.
|
| - Pair with said dev and talk it through in person.
|
| - He might just be a bastard, in which case normal solutions just
| don't work anymore.
| nfRfqX5n wrote:
| If I was your manager I'd like to know about stuff like this so I
| could try to help figure something out. Unfortunately it would
| feel like snitching for you and your actual manager + coworker
| might feel the same way. I usually try to avoid being a "problem
| employee", so often end up just going down the path of least
| resistance. It's a tough situation, especially if teammates who
| are senior to you struggle with leadership and decision making.
| stackzero wrote:
| Some quickfire help:
|
| - Agree on a team policy for code reviews, formatting, style,
| etc. (this alone should eliminate most of the subjectivity)
|
| - Read and share this https://google.github.io/eng-
| practices/review/ with the team
|
| - Design discussions could be agreed on before code is written
| axaxs wrote:
| So, I don't feel the senior person in this case is necessarily
| wrong. So many languages give you 30 ways to do anything, it's
| key for a team to agree on standards so that code is more easily
| read by everyone on the team. If you disagree about the style
| being suggested, don't argue back directly, but instead try to
| set up a quick chat with him/her and/or the team to suggest a
| different way of doing things. Having each member of a team
| having their own unique style gets annoying and confusing, to be
| honest.
|
| As for conflict in general... communication. Be absolutely
| direct, but not confrontational. Do not be passive aggressive, or
| round a bout in your words. That's always worked for me, at least
| - not for getting my way, but getting clarification in the
| shortest time possible.
| jeffrallen wrote:
| Be excellent to one another, dudes.
| gwbas1c wrote:
| A code review / pull request is supposed to be a discussion among
| professionals about how to make the code the best it can be. This
| includes:
|
| - (Onboarding)
|
| -- Making sure you use common style / naming conventions so that
| code is readable as different developers work on it
|
| -- Making sure you use common design patterns / dependencies /
| collections / ect, so that as different developers come in and
| out of a module, no one needs to re-learn things that just need
| to be the same
|
| [edit] -- Sometimes it's just hard for newcomers to know all the
| gotchas and longterm consequences. These should be patiently
| explained.
|
| - Readability: Make sure that variable / class / method names
| make sense
|
| - Ask questions: Sometimes a question in a code review means you
| need to add a comment in code
|
| - Knowledge transfer: A reviewer may have more experience with a
| specific API / pattern / technique
|
| Without knowing the specifics of your situation: It could be that
| your senior colleague just can't "let go" of the fact that they
| didn't write the code; or it could be a situation where your
| changes just don't fit with the overall architecture, style, ect.
| Most likely, one or both of you need to swallow your ego and
| prioritize the code over your own personal preferences.
|
| Side note: In general, you should always follow existing style /
| patterns / conventions in existing code, unless there is a very
| clear tangible problem with it. (IE, if all variables have
| 1-letter names and there's no tabbing, you probably don't want to
| follow style.)
|
| Anecdote:
|
| A few years ago, I got a surprise review request from someone
| from another team. They completely bypassed our dependency
| injection pattern and did "their own thing." The way they did it
| was a perfectly fine pattern, but it didn't match the pattern
| with the rest of the product. Long-term, it would create a huge
| maintenance problem if there were 1-off modules that used
| different patterns.
|
| I'm sure the other party thought that my review "can be
| summarized as his preference for doing things," but that wasn't
| the case: I was more concerned about long-term maintainability
| when other people needed to maintain their new code.
|
| Anecdote 2:
|
| In other cases, I sometimes block a review on confusing variable
| names. Yes, naming a variable "file" might make sense to a
| newcomer, but after working with the codebase for a long time, I
| know that "fileHandle", "filePath", ect, are much more readable.
|
| [Edit 2]:
|
| > also alters the relationship with that person for bad.
|
| Talk to your manager about that.
| thiago_fm wrote:
| Do more pair programming(preferably with him) and avoid having
| that issue at code review.
|
| Bring that issue up with your direct supervisor on 1 on 1s, if
| you have them.
|
| Is that just happening with you?
|
| Is he really just his own preferences, or something widely
| accepted, but you are fed up with him?
|
| I'd ask myself multiple questions and try to understand why does
| he do that, and also try to show some empathy and try to onboard
| more people on it. Work isn't only about coding, but also social
| relationships and navigating politics. You can learn a lot by
| facing the problem.
| aryamaan wrote:
| > Is he really just his own preferences or something widely
| accepted, but you are fed up with him?
|
| > Work isn't only about coding, but also social relationships
| and navigating politics. You can learn a lot by facing the
| problem.
|
| I generally do think about these questions, I will still try to
| be more mindful about them.
| nitwit005 wrote:
| If they're largely stylistic changes like whitespace, loop style,
| or something of that nature, you could just ask them to write up
| a doc on what they want. Many companies have such a document.
| Jemaclus wrote:
| This isn't specific to code comments, but one soft skill that
| everyone should learn is how to have conversations with high
| stakes. The code changes might not be high stakes, but having a
| good relationship with your peer is very high stakes.
|
| I recommend a book called "Crucial Conversations". You can find
| it on Amazon. It's a fantastic book about how to recognize that
| you're making "The Fool's Choice" (their words)... and how to get
| out of it.
|
| To apply the book to your case, you've boxed yourself into two
| options (I.e., The Fool's Choice): 1) I can argue with this
| person and could have an unfavorable outcome, or 2) give in and
| just do what they want. This is actually a false dichotomy --
| there are other options! One of the possible options is to turn
| that choice into a question by turning them into an AND option
| instead of OR options. In other words, instead of asking yourself
| "Should I make the code change OR make them hate me?" you should
| ask: "How can I nudge them toward my way of thinking AND _not
| piss them off_?" This alters your frame of mind, and you would
| approach the conversation much differently than you would before.
|
| Anyway, that's the gist of it. The book is fantastic, though, and
| I recommend you read it. It's a pretty easy read.
|
| Good luck!
| arminiusreturns wrote:
| It really depends on the situation, but in project management the
| list of conflict resolution goes like this (not in order):
|
| Force, withdraw, smooth, compromise, and collaborate.
|
| I don't like this model, I prefer the power, mediation, rules and
| needs model because it is more action oriented especially for
| people who aren't managers. If you think there should be one of
| them that doesn't exist (for example a rule) propose it up the
| chain, then use said rule to resolve the conflict. Sometimes
| maneuvers like this take time, for example if you want to use
| power but don't have it, it can take time to get enough to use it
| the way you want (and you need to think hard about if it is worth
| the potential fallout).
|
| Generally use empathy and discussion to use needs first, rules
| second, mediation next, and power as a last resort. That's my
| approach at least.
| muzani wrote:
| Robert Greene writes books on this, on how to tackle conflicts.
| 48 Laws of Power and 33 Strategies of War specifically.
|
| In this case, it's probably just best to tolerate it. It's
| tempting to try to discourage that kind of behaviour but it
| rarely works.
| weitzj wrote:
| Try to talk together and introduce a tool like a linter. Then let
| every member commit to the linting rules which should be used by
| the linter. This way you can decouple the review process and it
| will be the linter's fault and not a fault of any engineer.
|
| But really talk more in your team. Otherwise it is a
| disfunctional team. Agreeing on a ruleset for a linter is a
| start.
|
| Other idea: draft a ,,code review manifesto" with all team
| members and let everybody commit/follow this manifesto. Again it
| will be the consensus of the Team given by the manifesto/linter
| and not the individual person in case an argument comes up.
___________________________________________________________________
(page generated 2020-01-19 23:00 UTC)