A bit of context: I'm working in a small team of 5 developers at a startup. Our senior developer left about one month ago; he was by far the most knowledgeable of us in terms of the technologies we are using. His code reviews were always really good ones, as he didn't allow any code debt to get into production. During the months we worked together, I learned a lot from him and I'm really grateful for that.

Since he left, I'm really trying to help keeping the code quality as high as possible; basically like when he was part of our team. Thus, I'm doing code reviews in a thorough manner, trying to ensure the quality is on point. Here comes the problem: when this colleague puts code to review, I suggest him to try to do some changes for the better, but most of the times he responds like "I don't think this will help us", or "I don't think that is quite possible". This negativism and lack of confidence is getting on my nerves, especially when the solution I'm proposing is possible, but he spent only 5-10 minutes on investigating it to conclude it's not possible.

Another situation is when I suggest to add missing tests for a new piece of code, and his attitude is "Oh, not tests again .... ".

Similar remarks like these were also given by our ex senior developer, and I can feel that this colleague's attitude was a lot different than to my remarks. This attitude is not professional at all in my opinion, and I'm not sure what I can do about this. How could I proceed to make this situation better?

  • All the members do code reviews in the team. However, only 2 of us come with extensive remarks. And yes, I have an unofficial legacy to carry on, as the senior dev told me he puts his trust in me, and also mentioned my good implications to the management.
    – I. S.
    Commented Nov 6, 2021 at 19:29
  • Fair enough, it doesn't matter that much anymore. But what team doesn't want quality code?
    – I. S.
    Commented Nov 6, 2021 at 19:39
  • 4
    In the affirmation "But what team doesn't want quality code?" you're assuming that this is both a team and business priority. If you're so sure that your company wants quality code, bring this to your manager. However, be aware some companies do prioritize getting things done fast and cheap over doing them with quality. It sucks, but be aware of it.
    – Marc S
    Commented Nov 6, 2021 at 19:47
  • It is more the colleague than the colleagues (the others agree with me).
    – I. S.
    Commented Nov 6, 2021 at 20:22
  • 1
    Remind him that he'd have done it for the ex-senior developer?
    – gidds
    Commented Nov 7, 2021 at 23:52

3 Answers 3


First of all, look out for company policies regarding issues like testing. Even if there is no written rule and no manager at the moment, if the common practice was to write tests, I see no reason to stop doing it "just because".

Secondly, try to discuss and show your colleague why your suggestions should be considered. It is going to require a massive amount of patience and documentation, to make it clear that he is ignoring important issues. Keep record of such information, for example, the pull requests.

Finally, if your colleague doesn't agree to any of your suggestions, you think they are important, and his stubborness is causing disruption to the product quality or the team wellbeing, you will probably need to bring this issue to any manager, even if they are not technical. Give them the same reasoning you used to try to convince your colleague, alongside with the evidence in the form of pull requests. You can then suggest such manager to try to set up, perhaps with help from the team, some policies that enforce good practices in the code, like a minimum test coverage. Try to be extra careful when speaking to your manager on this topic, the problem is not "having a stubborn colleague", rather a lack of standards that let him do what he wants.


Your problem is that you are not in a position of authority or leadership, but you're trying to act as if you are. Similar questions pop up quite regularly on Workplace.

Your colleague is trying to get their work done as quickly as possible. They have been given some change to make. But every time the try to submit a new piece of code, your code reviews say they need to change it, and you complain that they haven't added enough tests. You are slowing them down in getting their task done.

Code quality policies have to come from above if they are going to be followed. And the people in charge actually have to believe in them. Your previous senior was that authority figure. You're not. Unless you can get the person who is now in charge of the team to start improving code reviews and testing, then you're wasting your time and getting yourself frustrated.

  • 3
    Authority should come from following team-wide choices with regards to definition of done, not from seniority. If the code doesn't meet the DoD, it does not pass review, regardless of who raises the issue.
    – Xizam
    Commented Nov 15, 2021 at 14:50

I agree with Simon B that the issue is primarily one of power dynamics. From your description it seems that you are not in charge of the team but you are acting towards your colleague as if. Clearly the senior dev that went away was in a position of power, not necessarily through a formal position, but through his seniority and expertise. Often in teams there is no formal leader, but of course power dynamics still exist.

Your goal to maintain code quality is a good one and one you all except for the colleague in question seem to agree on. But instead of trying to lecture your co worker you should work with everybody in your team and work out a code of conduct for code changes. This code of conduct should contain issues like test coverage, code reviews, etc. You should establish clear rules for what is acceptable and what not. Then you should use a software like SonarQube to help you with enforcing these goals. While working out these things you should always try to incorporate the opinion of everybody in the team especially the colleague in question.

After you established this code of conduct make sure that everybody reviews code from everybody and that it is not always you that reviews the code from the colleague you are having difficulties with.

Also try to let a few things slide and don't try to be a nitpicker. Focus on the things that are really important like testing. But some devs get obsessed with stupid and not really important discussions like whether you should place a "{" in the same line or the next line. Just use auto format. Also you don't need to solve every minor code smell in Sonar as long as it doesn't take overhand.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .