31

We have a developer that is known for rejecting PR during code reviews.

He sent me a message and asked me to come to his desk to discuss my PR.
He mentioned that he didn't like my solution and suggested to rewrite the code together.
So far so good, he is a senior developer and I'm sure I'll pick something from the pair programming session. He went with his approach and faced some issues that led us to my solution after nearly 2 hours.
I'm not angry because this scenario happened at least 3 times but how do you guys deal with senior developers that are stubborn?

Comments
  • 25
    Don't think in roles. He might have the job title as "senior developer". Yet when talking to him, he is just as much a developer as you. Act as such.

    Try to point out hardships that you faced that made you arrive at your solution in order to prevent them from wasting three hours. Yet if they insist: Wish them luck going in for that ride.

    If you want to pair, timebox your session before. (I'll can spend 1 hour with you on this.)

    Also try to get them to distinguish between nice-to-haves and must-haves. Certain offences should be fixed. Yet if it is a matter of preference or style, time is wasted.

    Just recently I had a similar experience where I was trying to state that I did something in a specific way due to weird dependency injection in the a certain service. I wasn't believed, and then we arrived at the very issue, and then I could state: That's what I told you. Now they understood.
  • 3
    @k0pernikus thank you for sharing!

    I guess the main issue in the current company is that developers don't distinguish between nice-to-have and must-haves while doing PR reviews.
  • 12
    One must not forget that shipping is a feature. And while there is always room to improve, it often is good enough to ship.

    When your solution is working in a pragmatic way: Defend your state. Challenge them about the hypothetical gain in business value.

    Not liking an implementation is not good enough to reject a PR. Naming reasons is.
  • 3
    @k0pernikus this is the best advice I ever received in my career!
  • 7
    I am one of those devs that deny 80% of the pull requests.

    If you can explain to me why you did it and more importantly why you didnt do it an other way Im probably gonna let it go 60% off the time.

    The main thing I do is making sure that people have thought about what they have written and its not against conventions
  • 2
    If you do have daily standups, first make your point clear to him, if he doesn't have convincing arguments to convince you or is to stuborn, suggest to discuss it at the next days standup. It will piss him off, for sure. At least at the beginning, but I'd guess it's a way for you to get more respect as a dev from your colleagues if you're sure, that you have a good solution at hand.
  • 0
    @vlatkozelka thank you very much for your feedback!
Add Comment