We are a small team of developers working on an IT project within a dedicated department. No hierarchy between us in that department, but one common goal: to get our main application up and running. We all work on the same code.

I am quite detail-oriented and take a great care when it comes to standards, clean-code and architectural concerns overall.

Now, one of the more senior devs happen to patch the code in a way that produces obvious bugs. Also, his code changes do not respect a certain quality standard. Basically, he introduces lots of bugs due to a care-free attitude, or at least a reason I cannot fathom at the moment.

The Department Manager does not care for cleanliness and operative details. He wants the main app to run and us to be able to add new features to it. He implicitly want us to take care of those details. I do think that quality standards and code maintainability is important, he has accepted that fact, but nothing is formalized in that sense. Pretty much "do as you must, it has to work I don't care how" territory.

I do not have the authority in terms of hierarchy to 'correct' the colleague. However, since he produces bugs, I want by mere friendly influence get him to avoid those bugs. I happen to hide those bugs from the manager and try to resolve them with said colleague first. He seems to be good willing but does not look like he learns. I have also in the past had verbal altercations with him since he thought I was meddling too much in "his affairs". But mostly, we get on quite friendly and have mutual respect. I might be perceived as a holier-than-thou guy, which does not help. I am nonetheless taking that mantle though, feeling the need for it.

How do you proceed to politely but efficiently help one such colleague to improve our code quality? This is mostly a communication question.

  • 8
    "I do not have the authority in terms of hierarchy to 'correct' the colleague." I don't understand. Why do you need authority in a hierarchy to correct a colleague? Commented Jan 25, 2017 at 12:05
  • 16
    Tip: Don't Tell him he introduced a massive bug -- tell him he introduced a bug, show what it does, and let him apply his own adjective to it. The first important thing is that it gets fixed. After that, ask whether the team as a whole ought to be testing better before committing changes...
    – keshlam
    Commented Jan 25, 2017 at 12:50
  • 2
    this question looks creepily like i wrote it...
    – amphibient
    Commented Jan 25, 2017 at 16:04
  • 3
    Ow do you expect the manager to see that code quality is important if you hide bugs from him?
    – HLGEM
    Commented Jan 25, 2017 at 16:13
  • 1
    At least personally, I would prefer to hear it right away if I had a big issue in a commit, before it causes bigger problems. Since "I" did the code, I most likely will know how to fix it quickly too. Don't you have code reviews where this could be noted, before it is merged to staging/production? Commented Jan 25, 2017 at 19:04

7 Answers 7


Hiding the bugs isn't going to do you any favours in the long run and has partly got you in this situation.

There's a couple of avenues to go down potentially:

  1. Just outright tell him that there's a bug - The friendly approach may not work as he has noted you "meddle with his affairs". So if you say I have found a bug because of X, then he can resolve it.
  2. Attempt to introduce code reviews - If you have freedom to implement working practices, then suggest to your team that you perform code reviews of each checkin. That way, you can review that checkin and point out the mistake in the review.

Don't fix the bugs yourself. If there is a way of logging bugs (do you have a bug tracker) then log them. You really need to try and get a manager on board to have some interest in quality of code. As you having to spot/fix your colleagues' code is taking you away from doing your tasks.

  • 1
    I can't believe #1 is a serious suggestion. The rest is sensible. Ping me when you've fixed the answer and I'll remove my downvote :) Commented Jan 25, 2017 at 12:06
  • 3
    @LightnessRacesinOrbit There is an element of seriousness to it. If the colleague doesn't react well to being told there are bugs (from the meddling comments) and management don't care, sometimes things need to happen that force management to care. Of course, in an ideal world he could do point 2, try to introduce point 3 and that would be that, but is it the OP's job to point out (or cover up) errors made by a senior colleague? It sounds like this happens often and simply saying not to do x or y hasn't worked yet. Commented Jan 25, 2017 at 12:15
  • 8
    Deliberately sabotaging a product because you can't work with your manager is gross professional misconduct. Raise the issue. If it's ignored, that's not your problem. But if you do not raise the issue because you want the issue to leak through to customers, for political reasons, that's very much your problem and as your boss I would have no problem in making that clear if I were to ever find out! Commented Jan 25, 2017 at 12:21
  • That's a fair point. I'll edit accordingly Commented Jan 25, 2017 at 12:28
  • It all comes down to the nuances of how to tell about the bug. I do like the code review, I have brought that to the management in the past to no avail.
    – darwin
    Commented Jan 25, 2017 at 14:55

Everyone make bugs, pointing out bugs in someone's code is like pointing out that you had a cough. It's only natural, no matter how well we prepare you cannot avoid it 100%, thus it shouldn't be a taboo.

Likewise, since everyone make bugs, there's no point in hiding them or not talk about them with people involved and if management has to know of existing bugs then just tell them, just don't play a blaming game.

Tell your colleague about the bug. If you care about the project and your integrity as an employee then you point out that you think the bug could have been avoided by following X,Y practices, you can ask if he agrees with you or not to make sure that you know his opinions about the matter.

We found a bug in A after the latest patch, we need to fix C,D. To avoid future bugs of similar sort I think it would be good practice to do X,Y, do you agree? If not, what do you think we can do differently to avoid this?

If there are no official guidelines then there's not much you can do beside trying to suggest better practices, but if he absolutely refuses to listen and you truly believe that he is not suitable for the project because of not giving a damn in general about how he does his job then you need to bring it up with your closest manager and after that simply accept the outcome of what your manager wants to do or doesn't want to do.

If you want management to care more about code quality, however, simply give them examples on how not following certain practices could and has lead to certain bugs in the past, not only in your project but in others' and explain the impact. People don't care about things they don't understand, if they understand why certain practices must be followed then they'll be more likely to enforce them.

  • I'll keep on suggesting changes, on management level I don't feel I can reach the results I expect. I have tried various methods, without success. Letting the problem be is also not how I want to do things.
    – darwin
    Commented Jan 25, 2017 at 14:57
  • Understandable. Do your best, if nothing works you simply have to evaluate whether you wish to work under those circumstances or not. We can only try to change the world but at least we are privileged up to a certain degree to choose where we work, or at least where to not work.
    – Jonast92
    Commented Jan 25, 2017 at 15:26

If you don't want an open discussion with the colleague, you can use his stuff in a way that will trigger the bug. What you do then, is

  1. Log the bug
  2. Make a test case
  3. Fix the bug. Keep the test case as proof
  4. Fix related issues

We don't care about that right now, you should be focused on X

This is fair criticism you might face for devoting resources to a problem that isn't a problem yet, in which case you might wanna drop steps 3 and 4 from above.

Talking to the colleague is of course the best thing to do, my answer provides an alternative to the ideal.


I think you're having difficulty in knowing how to say something because you feel invested in the result. And rightly so, since you two are friends and colleagues.

But I also feel that this is one of the those times you just have to let it go.

If you value your friendship and work atmosphere, then you just have to accept this aspect of your friend and move on.

Then, armed with this attitude, you can proceed to actually solving your problem.

Just tell it to him straight.

It's at times like these that I recall something I had learned in middle school: I-messages.

"I feel annoyed when you produce work with bugs because then I have to fix them. I really wish you wouldn't do this anymore."

I feel...when you...I want.

If this doesn't work, then I would change my approach to the problem, that is, I would match his attitude and let bygones be bygones because, after all, you never really know who the better engineer is.

  • 1
    "I feel annoyed when you produce work with bugs because then I have to fix them. I really wish you wouldn't do this any more." This is quite a hostile phrasing. It invokes a "me vs you" mindset. Contrast this with Jonast92's suggestion of We found a bug in A after the latest patch, we need to fix C,D. To avoid future bugs of similar sort I think it would be good practice to do X,Y, do you agree? If not, what do you think we can do differently to avoid this? This is very much an "us vs the problem" mindset.
    – RJFalconer
    Commented Sep 13, 2017 at 12:39

Do you have mandatory code reviews? My feeling is that the answer to that question is no. If you did, that is where such exceptions should be caught, documented, and the change rejected.

Do you have an issue tracking system such as Jira? You should document your findings, include file differences, and describe how they introduce a defect. Also, describe a series of steps for how to reproduce the defect caused by the poorly implemented code change.

You should make your objection as formal as possible, and use hard, demonstrable facts, not opinions. This is not a matter of "soft skills", personality or opinions. It is a matter of easily demonstrable incompetence and you should document it as such, visible to your superiors. They should choose a course of action. In my 20 years of programming experience, admonishing a coworker over the type of objections that you have and that I have had many times, is mostly useless. But if you cannot lucidly demonstrate your case in a way that is understandable to someone of decision making power, it will likely fall on deaf ears.

If your higher ups do acknowledge your grievances, hopefully you should be able to present a case to implement mandatory code reviews as part of the SDLC, which I suspect someone of your proclivities should welcome.

  • Thank you. We don't have either of those; I consider them as you say as being essential to the quality output. I am trying to enforce the tracking (which is more or less resolved by sending mails usually) - but the code review I am most interested in. How would you deploy this, and manage the egos? My fear is one of hurting programmers in their pride.
    – darwin
    Commented Jan 26, 2017 at 13:20
  • the code review has to be a mandatory step of the SDLC that stands between a change checked into a feature branch in your VCS and the main branch from which it is deployed. No change should be able to sneak into a deployable branch before it is reviewed. It works differently with different VCSs so it depends what you're using
    – amphibient
    Commented Jan 26, 2017 at 14:12
  • I see, but here I am more interested in the psychological side of it. There is reluctance to accept that such processes can and should be necessary. To management, I can tell you, it reaks of "too complicated for what we do". I see the necessity of it though. My problem is not a technical one; it is one of conveing an idea.
    – darwin
    Commented Jan 27, 2017 at 11:38
  • I'm sorry, I can't offer advice in the domain of "psychological"...
    – amphibient
    Commented Jan 27, 2017 at 16:23

It usually happens in products your company doesn't have to maintain, or projects where the project manager has not enough programming skills. The only thing you can do is report your project manager and your team colleagues the problems you are facing maintaining this project without complying the quality standards, and show numbers. If the client accepts this loose of money, the most probably is that nobody cares, just the person who faces the hell. If it is a closed budget project or a project you usually maintain yopur company will hear you. The most easy thing is to detect the bug and help him untill he learns enough to solve the problems himself.


I've tried code reviews on a couple teams, but they are a burden that requires ongoing management support. Tough to get buy in. And not infallible.

What worked for us was each developer had to produce documented unit tests. This way they usually caught their errors before deployment to user acceptance testing.

For larger complex projects we had teams of 2 or more analysts create the unit tests for the coding teams from the design/ requirements. They would run these tests for the team as a whole. That didn't eliminate unit test requirement, but added the layer needed to ensure all activities from the development team held together as a whole.

Making documented unit testing part of the process of committing code for each person on the team ensured that the seat of the pants developers used proper discipline with out singling out anyone.

Defects for the team dropped 80% or more with this discipline in place. On call support effort dropped to the point we almost never got called after a new deployment.

Test plan complexity/formality was adjusted based on the level of impact...often just a paragraph long for small changes...but expected results and actual results had to be documented (screen shots, etc).

After the success of enforcing this within our team for several years the QA team introduced this requirement to the whole IT department (they did this independently as QA matured at our company).

Occasionally we would do code reviews on new team mates or when working with new technologies. But that does not sound like your issue.

With a new application we were building, we started documenting and saving the unit test plans so they could be reused. We were using Team Track to do this. It wasn't quite the best tool, but it was better than a library of word documents. It allowed us to select which features needed testing, and we could edit the plans to document our changes. Then we could run through all the related test scenarios and document success or failure.

You must log in to answer this question.

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