So a bit of an update to this question.

I realize I need to be more polite about calling out bad code. This scenario has come up again and I have found someone's code that has introduced a bug. Note that I have introduced plenty of bugs before and I am not the one to judge. I am just stating that this has happened again and I want to go about things the right way.

This person already doesn't like me and is already sensitive about his code. He is also a senior software engineer while I am just a regular software engineer. How should I do this? Note that we are both working remote. My honest best guess is to just message him. I know he doesn't want to hear or see this but I don't know what else to do. Let me know what you guys think.

Update: I have talked to a higher up and they have told me to go to the person that coded it. This is a person that doesn't like me and is ultra-sensitive about someone telling him his code introduced a bug (even politely). Wish me luck.

  • 14
    Who has NOT introduced a bug into a codebase?
    – jwh20
    Commented Sep 15, 2022 at 15:54
  • 3
    @jwh20 Everyone has
    – Slaknation
    Commented Sep 15, 2022 at 16:33
  • 2
    @Slaknation My point exactly. I don't get why this is a big deal. Just handle it professionally. If the "senior" developer is really a senior developer then he already knows how this goes. You fix it, you fix the test(s) that missed it, you review your procedures for reviews, and you move on.
    – jwh20
    Commented Sep 15, 2022 at 17:18
  • 4
    I don't understand why you need to tell the author of the bad code. Can't you just put up a review to fix it? Commented Sep 15, 2022 at 17:30
  • 1
    @Slaknation Speak to your manager and follow whatever process they want you to follow. If that involves creating a ticket, getting it approved, making the fix, making a test plan, and then waiting 3 weeks, so be it. Commented Sep 16, 2022 at 1:17

4 Answers 4


Follow your companies standard procedure for fixing bugs, whatever that is. If no procedure (!), raise a ticket, assign a developer (or take it yourself) and fix it. No need to make it personal. If the bug slipped through because of a gap in testing, write the tests also.

If the bug ended up visible to (and affecting) client users, write a root cause analysis if needed; but again, concentrate on the bug, not who wrote it.

Fix the bugs, not the blame. You'll appreciate that, next time you introduce an error yourself.

  • I honestly don't mind when people call out my code introducing a bug. I take responsibility and fix it.
    – Slaknation
    Commented Sep 15, 2022 at 16:04

"His code" is a red flag pointing out an underlying problem in your team's or organization's culture. While fully collective code ownership isn't always possible, your team needs to accept shared responsibility for its code, independent of who originally wrote it.

This of course means that you need to be able to talk about issues you find in the code (not "his code"). It looks like trust within your team is already damaged quite a bit, so doing that in a way that improves trust as well as the actual code quality would be important. How you can approach it depends on many factors, your own personality traits, the other person's personality traits, organizational and managerial environment, etc.

I'd probably try to get a solid case (i.e. know exactly in what situations the code can fail and why) but present it tactfully and lightly, not confrontationally. Something like "Hey Bob, I think I may have found a case in which the code doesn't do what it's supposed to do, can we sit down together to have a look at the details?" (with screen sharing if you work remotely).

If the relation between both of you is broken so much that Bob does not want to listen to you, you may need to escalate this to your manager, not to point fingers at Bob but to open up communication channels and probably clear up interpersonal problems.

The ultimate goal should be that you and your teammates trust each other that you don't fear bringing up issues in your work.

  • 3
    A developer introducing a bug to production is also a failure of the process, not the person. This is why we have code reviews, QA, change control, etc. People make mistakes, which is why we put processes in place to catch them before they become a problem. OP should be examining how their system failed, not the developer.
    – Seth R
    Commented Sep 15, 2022 at 16:04
  • @SethR I am 100% in agreement with you. Our culture is not good. When I first came to the company I did normal code reviews where I actually added comments when I saw that someone's code was bad. But coworkers didn't like that at all so then I just learned to "just accept" Pull Requests (which is what everyone does). This is not the culture I would choose, but I am not a Senior Dev so I don't have a choice.
    – Slaknation
    Commented Sep 15, 2022 at 16:08

How to approach someone who introduced a bug to the codebase

Unless code review is your responsibility within your organization, focus on the bug, not the code or the person.

Demonstrate in detail to the team responsible for handling bugs in the application how the application is broken and let the team leader or whomever is in charge decide what the next steps should be. This way, you are not accusing any specific person of introducing a bug and you are not making any commentary/critique on any specific person's code.

If you do feel it necessary to reach out to the specific individual, you follow the same mentality. Demonstrate in detail how the application is broken and let them decide what to do.

In either case, since your team appears to be sensitive to criticism (or sensitive to you), you should approach the subject as an "unexpected behavior" in the application rather than a "bug".


I am going to turn your problem on its head

Don't blame the person, blame the process.

Bob (your unnamed senior engineer) didn't introduce a bug into your application code, yes he wrote it. But your companies review process should have caught the bug before it allowed the bug to join the code base. That it didn't means your teams development process is flawed.

Why am I saying this?

If debugging is the process of removing software bugs, then programming must be the process of putting them in. Edsger W. Dijkstra

I have yet to meet anyone who writes bug free code for anything complicated. However with test driven development, and a good review process you can catch most* bugs before they end up in your code base.

* It is almost impossible (inside of any complex system) to prove that bugs don't exist, just that you cannot find any.

What I think you should do?

Ask why five times.

  • Why did a bug get introduced into your codebase?
  • Why did it get pass a peer review?
  • Why was it not caught with unit tests?
  • With functional tests? ... But thru all of these whys I want you to remember, its not a persons fault, it is your process's fault.

Work with Bob, and other members of your team to improve your process so that you catch bugs before they move into your codebase. Have code reviews.


I just read your linked question... And yes, the company you are working at has a serious process problem. If you want it to change you are going to have to take ownership of the problem, and fight against a mountain of technical debt, as well as fight against a work culture which is ignoring the problem. Or you can leave for another company which will probably have similar problems.

  • haha I tried to do actual good code reviews myself but everyone got mad at me and when anyone does a good solid code review people complain that your not just accepting the pull request. So yes, I have tried fighting it, but because I am not a sr dev, I have pretty much been silenced.
    – Slaknation
    Commented Sep 15, 2022 at 16:44
  • 1
    Have you tried to have people do solid code reviews of your code? Or just other people's code? If you are really frustrated, I think you might want to polish your resume up and start hunting. The job market is still pretty hot right now.
    – Questor
    Commented Sep 15, 2022 at 16:52
  • 1
    Should I start to tell people to do a better job when reviewing my code? I mean, I'm not sure that's a good idea. They'd probably just tell me to write better code.
    – Slaknation
    Commented Sep 15, 2022 at 16:59
  • 1
    Also, what am I going to tell companies that I apply to? That I want to find a company that has a better software development culture?
    – Slaknation
    Commented Sep 15, 2022 at 17:00
  • 1
    @Questor I have tried this. The rare person or 2 that does good code reviews. I tried talking to 2 of them (that only do code reviews for our team on rare occasions), and they both seemed to not want to talk about it.
    – Slaknation
    Commented Sep 15, 2022 at 17:45

You must log in to answer this question.

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