121

I'm a junior software developer in a small company. I'm working on a project since I finished my internship contract 4 months ago. It's a small project, so there's only another programmer (junior too but with ~3 years of experience) and the project leader, who doesn't even see the code. Every time the client finds a bug, the project leader informs both of us because he doesn't know who made the mistake.

The problem is that whenever he informs us about a bug, my colleague tells him it was my fault, without even checking if that's true, and sometimes the project leader speaks to the company boss. Then, when I go to source code to find out where the problem is, I usually discover that he wrote that specific piece of code (thanks to git commit history), but as it is not inmediate, I cannot defend myself.

The thing is that I'm not really sure that the other developer does it intentionally because it's easy to blame the "boy without programming experience who doesn't know how to do things right", or if he really thinks the errors were mine because of the same reason and that he doesn't remember which parts of the project he wrote.

In any case, what can I do to show my project leader and my boss that most of the errors I'm blamed for are not mine without accusing him explicitly? I fear for my future promotions and the opinion of my boss about me.

Improve this question
7
  • 33
    @Alex, is there a specific concern you have in not wanting to confront your colleague or accuse him/her directly? Is there a reason confrontation would be bad?
    – Jay
    Jun 25, 2019 at 11:32
  • 7
    Did you ask him why he's first blaming you for the error without checking?
    – Dan
    Jun 25, 2019 at 12:26
  • @Jay The reason is that I don't know if he does this intentionally. He might just think that the errors were mine because he doesn't remember programming that specific part of the project. And I don't want to sound rude when maybe he didn't do that intentionally.
    – Alex
    Jun 25, 2019 at 12:58
  • 7
    @Dan no, I didn't. I said something like "Hey, I've checked this code and it seems that you are who wrote this part" so he realises the bug was not mine. But he always says something like "Oh, ok", nothing else.
    – Alex
    Jun 25, 2019 at 13:01
  • 1
    Responding to some of the comments here, I would only confront your coworker if you are certain they are not acting in bad faith. If they are--if they are trying to sabotage you or if they are a psycopath/sociopath, then confronting them may give them more ammo to harm your reputation with the boss ("Alex has been attacking me for pointing his bugs out to him; he's not a team player"). Instead you can take the high road in the meeting and divert way from the blame game to a methodical troubleshooting process (see my answer for more details).
    – bob
    Jun 27, 2019 at 15:06

13 Answers 13

Reset to default
203

Then, when I go to source code to know where the problem is, I usually find out that he was who wrote that specific piece of code (thanks to git commit history), but as it is not immediate, I cannot defend myself.

Two approaches here. If the policy is "whoever caused the bug fixes it", then you just push back:

I've investigated this issue, but it seems to be in x which isn't code that I've written. Alex, I believe you were the original author here - could you take a look?

Do that every time. If it happens often enough, then Alex starts to get himself a reputation for blaming others for his mistakes.

Alternatively, if it's a recurring problem (sounds like it is), and you feel that you're being viewed negatively because of it, then your reaction doesn't need to be immediate. You need to log every time this happens, and then take it to your manager:

Hi boss, I'm feeling increasingly uneasy that most/all bugs that come through are being attributed to my contributions. We're all human, and I'm certainly not claiming to write perfect code, but in the last (few weeks) I've had issues a, b, c and d highlighted as my responsibility despite them being caused by code that I've never touched. This seems to be an ongoing issue. Could you have a word?

Improve this answer
10
  • 43
    You use git blame to determine who modified a line on a file. However, a lot of folks might think of blame as being negative. So you should be careful telling the boss you ran git blame but instead simply say the last person to modify that code was... or the revision number.
    – Dan
    Jun 25, 2019 at 14:29
  • 50
    @Dan I mentioned nothing about git blame for that very reason.
    – berry120
    Jun 25, 2019 at 14:31
  • 25
    @Dan @berry120 you could use git annotate instead (ref).
    – Bas Peeters
    Jun 25, 2019 at 21:03
  • 38
    git blame only says who modified a line. if you want to find out which commit causes a bug, use git bisect to manage checking out your code from different points in the git history (it goes back and forth between a known good commit and where the bug is known to occur recursively until it lands on the first known instance of it).
    – Derek
    Jun 25, 2019 at 23:23
  • 14
    Contacting the manager is the most important part of this. The colleague always assuming and proclaiming you're the cause of the bug is just downright insulting, and creates a hostile work environment, which will hurt morale and productivity. The manager should definitely be taking steps to stop this kind of behaviour.
    – Wipqozn
    Jun 26, 2019 at 12:39
61

There are too many dysfunctional behaviours here that it will be hard to fix them if the other members of the company don't know how a dev company should work.

  1. Your colleague shouldn't be in a position to blame you. As I understand, he's not your superior so he shouldn't be allowed to do so and your superiors should discourage such behaviour.

  2. Your project leader shouldn't be interested in who actually coded the bug. He can report to the team the found bugs, then manage how to solve them. But not listening to your colleague blaming you, he should even dislike it. Teammates blaming each other is a sign of bad company health and it should be frowned upon.

  3. Bugs happen in software development, and people prefer focusing on solving them than spending time to find who did the bug.

That said, you need to approach your superior not to discuss who made the errors, but how to find an efficient method of bug tracking, bug fixing without losing time in finding who's to blame.

Improve this answer
12
  • 16
    Your point 2 is what I've consistently found in my experience. It's not particularly important who introduced the bug, the important thing is fixing it and you just assign them based on workload and area of expertise (if applicable).
    – pboss3010
    Jun 25, 2019 at 11:48
  • 2
    I would argue that it's important to know who caused the bug, so that it could be assigned to that person to fix it. Otherwise people stop caring about the quality of their code, if they can always dump their problems on someone else.
    – Dragan Juric
    Jun 25, 2019 at 14:29
  • 7
    I would add to this that how bugs can be better mitigated in future is more important than determining who "caused" them. Do we have missing test cases? Do we have gaps in requirements? Do we need peer review or pair programming? The situation where someone can be "blamed" for a bug points to a fundamentally broken software development environment.
    – Ant P
    Jun 25, 2019 at 19:47
  • 5
    @DraganJuric that's not how healthy software teams operate. The team as a whole is responsible for the software as a whole. Who "wrote the bug" is irrelevant - the team needs to fix it.
    – Ant P
    Jun 25, 2019 at 19:51
  • 3
    @AntP: I've found that code reviews also help with the right mindset: if a bug makes it to the codebase, then the reviewer shares part of the blame. This helps with getting into the mindset that responsibility is shared across the team.
    – Matthieu M.
    Jun 26, 2019 at 11:45
28

Speak up for yourself!!

The only reason that your colleague is making you look bad is because you are allowing him to. He is making a claim in front of your manager and rather than challenging his claim you are simply doing nothing. This needs to stop. The next time that he blames you in front of your manager for a bug you need to speak up with something like:

Are you sure it is my fault? I don't recall working on that part of the project. Let's look at the git history to be sure.

And then you should make sure you all look it up ( preferably with your manager present ) to confirm or deny his claim. If the manager cannot be present, you need to follow up with the manager with your findings and copy your colleague. The colleague needs to understand that you will no longer allow him to get away with accusing you for bugs without first investigating.

Improve this answer
5
  • 3
    I think this is a critical step. No software engineer should be claiming to know the root cause of a bug unless they can back it up with analysis. Overtly requesting your colleague to show you their analysis and explain how they know the bug to be your responsibility will either a) show you it's your responsibility and save you some debug time or b) expose the other engineer as being premature in their analysis.
    – Dancrumb
    Jun 25, 2019 at 14:32
  • 1
    Wish I could + more. I would hit back both at the fact they're blaming without evidence or checking; but also that they're blaming at all. I feel it should be highlighted the important question is "how do we make it so this doesn't happen again" rather than "how do we make Dave feel bad"
    – UKMonkey
    Jun 26, 2019 at 9:27
  • 3
    Upvoted. This is my gut reaction. If someone told me something was my fault and I know for a fact it wasn't, I'd have no issue with calling my colleague out (professionally) in front of my manager. Blame cultures should not be tolerated especially when the person being blamed is not at fault. Even if it was your fault, your colleague is being unprofessional by calling you out. S/he should being fixing bugs with you as a team or agreeing with you in private that either you or they will fix it alone.
    – Jamie Butterworth
    Jun 26, 2019 at 13:06
  • This is good, but only works (without lying, which should be avoided) if OP really doesn't remember working on that part of the project. It also implies that the bug lies in the part of the project in which the problem manifests, which is often not the case. See my answer for a more general solution.
    – bob
    Jun 27, 2019 at 15:01
  • Perhaps "how can you know whose fault it is without first finding the root cause?"
    – Technophile
    Jul 7, 2020 at 17:28
15

I usually discover that he wrote that specific piece of code (thanks to git commit history), but as it is not inmediate, I cannot defend myself

In a single phrase: Your Source Control system of choice (git/tfs)

The ole saying goes the code don't lie. If you are blamed for a change you did not make, you should be able to say "well, let's look at the history" and clearly demonstrate who made what changes to the code to cause the bug. Sit with your manager, show the history and clearly explain why this is the issue, and that should be the end of the discussion.

As a developer, our documentation for the most part is source control. If we cannot rely on that for cases like this, I am not sure what you can do. I will say though in my many years of experience, using the source code as my defense, and I am in the right, always works.

This approach also allows you to deal with the issue with no confrontation with anyone. You don't even have to say the name, you can say this change set as I demonstrated clearly caused this issue.

If you cannot use your source control system to defend yourself in cases like this I am not sure how you can.

In almost any situation, developer or not, documentation of some kind is your friend.

Improve this answer
8
  • 2
    git-blame - Show what revision and author last modified each line of a file
    – Underverse
    Jun 25, 2019 at 12:04
  • 3
    Really like this answer. Only addition I'd make, to be even less confrontational, is not necessarily sit with manager. Just a carefully crafted email of the form "I tracked down the bug to commit xyz, here's the commit summary" and put enough in to make it clear as to who generated the error.
    – DaveG
    Jun 25, 2019 at 12:23
  • In fact we're already using Git, so it is easy to check who made the last changes, the problem is that the project leader never reads the code, he is just an intermediate between the client and us, so he doesn't see the blames.
    – Alex
    Jun 25, 2019 at 14:00
  • @Alex You have to find a way to show him. Take screen shots of the offending parts of the code along with who did them. If you cannot use the documentation to defend yourself you have no real shot in this scenario.
    – Neo
    Jun 25, 2019 at 14:14
  • 3
    @Alex Make sure not to assume that the programmer who introduced a bug is the programmer who last edited the code with the bug. In my experience the last edit is rarely the original introduction of the bug, except for obvious bugs.
    – Matt
    Jun 26, 2019 at 11:26
10

Tricky. The key player here is the project leader and their impression of you.

If the project leader are good at reading people and situations then they will notice that you are blamed for every error and that this is unlikely to be true. If, on the other hand, they are not good at reading the situation then there is probably very little that you can do. In both situations they would view you less favourably if you make a big song and dance about the issue.

The best bet would be to make them aware as gently as possible. Pick a low pressure moment when you are speaking to them one on one and raise the issue (e.g. during a performance review). I would say something along the lines of:

"Have you noticed that X tends to blame me for bugs when they get escalated? I just wanted to make sure that you are aware that it isn't always the case. When I'm fixing the bugs I usually find that I wrote the code about Y% of the time. I don't think that this is a big issue but wanted to make sure you don't get the wrong impression of my work."

Avoid pressing the issue. You want to draw as little attention to it as possible just so long as your supervisor is aware.

It might be worth having a couple of examples ready but I wouldn't bring attention to them unless your project lead asks for examples.

Improve this answer
1
  • Project lead might be inexperienced in software development as well, and trusts the "more senior" guy to be right for design decisions and where to place the blame.
    – Phil M
    Jun 25, 2019 at 23:28
10

One option is to bring up the last few incidents when he blames you the next time. Say something like "Are you sure it's my code? The last few times you said that, it turned out to be your bug. Perhaps we should get the revision history before assigning blame."

That makes it clear that you were wrongly blamed in the past, and that you think he should actually check before blaming you next time.

Improve this answer
4
  • 2
    Yes, the most important thing here is not to convince your colleague to stop blaming you, but to show your managers that he's producing the bugs, and blaming you on top of it. He's most likely to stop the blaming if that double whammy becomes public knowledge
    – user90842
    Jun 25, 2019 at 23:35
  • 3
    Much easier: Since he just said "It's your fault" without checking, you just say: "That's what you always say. You're wrong, I checked it, it's your fault".
    – gnasher729
    Jun 26, 2019 at 5:48
  • 1
    This is on the right track, but you want to avoid throwing the coworker under the bus. It makes you look bad and contributes to the toxicity. Instead you can redirect from blaming people to troubleshooting the bug (see my answer).
    – bob
    Jun 27, 2019 at 14:58
  • 1
    the OP is not throwing the coworker under the bus, this is self-defense, which is very different
    – user90842
    Jun 27, 2019 at 22:46
10

Ask your project leader

The problem is that you are finding that your colleague is blaming you for your colleague's bugs. Your project leader is the person hearing that. How do you let your project leader know about this? Schedule a private meeting and ask what to do. You want to know

  1. Does this matter? Is who caused a particular bug tracked in some way?
  2. Should you be reporting when the initial report is different from the actuality?
  3. How should you handle this in general?

You should take at least three examples of bugs that were originally reported as yours but were actually your colleague's. These should be clear examples. If it might arguably be your bug, you shouldn't include it.

By asking rather than reporting, you take some of the sting away. You're not giving the project leader more work. You're just asking for guidance as to what to do.

Your project leader knows more about the culture and procedures at your company than you do. You may be worrying about nothing. Or this might be important. We don't know because we don't know about your company. Only people at your company can tell you, and the most natural person for you to ask is your project leader.

Another issue is that you don't know why your colleague is blaming you for these bugs. Is it insecurity? A dislike of working on bugs? Something else? The next time this happens and you find yourself alone with your colleague, you could tell your colleague that you tracked down the bug and it was in your colleague's code. Say this casually, just as a point of interest. Something like, "Hey, you know that bug you said I caused, turns out it was in your code. Do you just want me to fix it?" The response might be illuminating. But ultimately, it's not your job to manage your more senior colleague. That's why you have a project leader, to worry about that kind of stuff.

If your project leader reacts negatively to your questions, you can always start looking for another job. But your project leader should give you feedback as to how to handle things at this job. If your project leader tells you just to ignore it, then ignore it. If your project leaders asks you to document it, then document it. If your project leader tells you to talk to Human Resources, talk to HR. That's why you have a project leader, to give you direction when you are unsure what to do.

Improve this answer
4

There are 2 problems here:

  1. You have a toxic coworker. These are the kinds of people who wreck teams. If you find yourself on a team with this kind of person in the future, change teams or companies. But the real problem is:

  2. You have a clueless manager/project lead. The Pointy Haired Boss (PHB) in charge should note that Toxic Tom is constantly pointing fingers and assigning blame, even before anyone has had a chance to review the code. They should think to themselves: "There's no way that Toxic Tom could have analyzed the code that quickly to locate the bug...I just told them about it!"

This is actually the bigger problem, and a good reason to get out of there as fast as you can. A boss will make or break your career. A good boss will recognize your effective work and leverage that to advance both of you. A bad boss will ignore your blood, toil, tears and sweat and leave you groveling in the gutter and backstabbed by lowlife peers.

If you had more confidence and experience, you could coach all 3 of these people to be better employees. But the fact that they all work together in this company tells you everything you need to know. You are working for a low-quality company. Probably almost anyone else that will hire you will not be worse, with a good chance they will be at least a little better. Keep hopping around until you find a good boss to work for. Anything else is a waste of your life.

tl;dr: If these people were really capable of change, they would have already left. This is a warning sign to get out of dodge.

Improve this answer
1
  • ...and if you jobhunt, it's taboo to badmouth previous employers, even though hiring managers know that 90% of vacancies are permitted by bad bosses. But updating your resume, and not resigning until you have another job offer accepted, is desirable.
    – Christos Hayward
    Jun 28, 2019 at 19:22
2

Follow up because this is something that hits close to home to me and i feel like the current answers don't cover the most important aspect about software development.

This may not be the answer you like but in my professional experience understanding this will go a long way.

Code reviews are not just for code quality they are also for shared responsibility, if you review eachothers code before it's merged in then you have a shared responsibility of the bugs. This same strategy is deployed in sailing ships, one person rigs everything and the other person checks it; that way if anything goes wrong both people can only blame themselves because if it was rigged wrong the person who reviewed it is now responsible.

Any strategy deployed in any team to create individual responsibility for bugs will be detrimental to both the team culture and to trust within a team which is what has happened here.

Improve this answer
2

How to defend yourself during the "blame placing" meetings

Speak up for yourself in those meetings! Redirect the blame process (which is toxic) by pointing out that until you and your coworker sit down and carefully trace the source of the bug, it is impossible to know for sure what is causing it (it's well known that first guesses about the cause of bugs are almost always wrong). Make sure to setup the follow-up troubleshooting meeting with your coworker right then and there--something to the affect of (let's call your coworker "John"):

"John, lets troubleshoot this together; this afternoon work for you?"

This short-circuits the blame process so that no one gets blamed, and it makes you and John both look better. You show professional maturity, and he shows that he's a team player and is willing to stop jumping to conclusions.

Why this approach?

  1. It prevents you from taking an unwarranted hit to your reputation with your boss.
  2. It shows you to be a team player who knows good software process.
  3. It refocuses the team from placing blame on people (which is toxic) to finding and fixing bugs.

If your coworker keeps arguing with you or lies, just repeat that you guys need to sit down and walk through the code to be sure, and make sure to push for the pair troubleshooting meeting. If that fails, then have a sit down privately with your boss.

Do not throw your coworker under the bus in the "blame" meeting. It will make you look unprofessional. If you need to address your coworker's toxic behavior with your boss, do so privately.

Here's what this approach looks like:

Your coworker:

Alex wrote that bug!

You:

Hold on a second. We need to sit down and look through the code and carefully trace where the error is occurring and what caused it before we can be sure where it is occurring. We don't know those details yet.

Your coworker:

Yes we do. The bug is with component Foo. It no longer works. You worked on Foo last / you wrote Foo, so you wrote the bug.

You:

It's not that simple. Components are interrelated, and while the problem is manifesting in Foo, that doesn't necessarily mean the bug is in Foo. It may well be in Bar. We've found that to be the case many times in the past (and first guesses about bugs are almost always wrong in general), and that's why it's important that we carefully troubleshoot this and other bugs so we spend our time wisely. Let's walk through this together and figure out where the bug lies. Are you free this afternoon?

Your coworker: (mumbles)

Sure.

Improve this answer
1

You should confront your colleague and discuss the issue with your manager.

Ask your colleague for 30-min to catch up over coffee. Let him/her know you have some feedback to share about they way you have been working together and are open to any feedback they may have for you.

In the conversation, be direct in sharing your observations with your colleague and explaining how it is making you feel. If you have specific examples, include 2-3 (but don't come with a list of every occasion, as that is a little too aggressive and formal).

After your discussion with your colleague, ask your manager for ~1-hr to informally discuss how you are feeling at work and an issue you are having with a colleague.

In the conversation, again, be specific and direct about the experience you are having - there is no need to play down what is happening. Be honest and transparent.

Ask your manager to review a handful of examples and advise you on how to better work with your colleague. Your manager should make his/her own decision about confronting your colleague.

In the end, you colleague will likely be embarrassed and may be unhappy that you outed him/her. However, the behavior you describe is not acceptable. Given the behavior is persisting - you should work to intervene and invite your manager to intervene.

Improve this answer
3
  • 3
    @Niko1978 How is using the words "I feel" manipulative? Is there a reference for this? Usually the use of "I feel" is a defense against potential attack because no one can dismiss how a person feels about something. If there is an offensive aspect of this approach I would like to know of it.
    – Underverse
    Jun 25, 2019 at 12:13
  • 1
    Having endured it from a high order S personality type manager I completely understand. From most people it is a way to express themselves without feeling that they are exposing themselves. People who attack with civility, or in similar fashion, make for the worst work colleagues. You have my sympathy.
    – Underverse
    Jun 25, 2019 at 12:26
  • The risk here is that there's a good chance that the blamer is acting in bad faith. If that's the case, this approach is likely to provide them with more ammunition to use against OP.
    – bob
    Jun 27, 2019 at 14:56
1

How's the QA process in your organization? Is someone assigned to ensure that the project is free of bugs before delivery to the client. Are you two developers allocated time to perform basic testing and bug fixes?

Also, does the team maintain proper documents listing project specifications and who is responsible for which module?

Since you mentioned it's a small company, it's likely the company may not have the resources or time to dedicate for a QA/testing team. Also, you may not have properly documented specs and module division between the developers.

You can resolve this situation by proposing the project leader to let you allocate some time for QA and bug fixes. This would ensure that the deliver going to the client are free from simple issues.

To guard yourself against incorrect blames, start by preparing a document that lists down the project specifications. Try to segregate the various modules between the two developers such that both of you can work independently. Do this while in agreement with your project leader and the other developer. Take the initiative to draft the first version of this document yourself (even if you have to spend some overtime doing it). Having an initial version ready would make your colleagues more willing to discuss.

Once you have the modules segregated, and the same is consented to by the project leader, you won't be blamed for your colleagues work.

Integrate proper source control practises into your workflow. Using it, both of you can choose to work on independent copies (branches) of the project, merging only after each of your's work is tested. It may entail some learning curve in the beginning, but would be worth the effort. Git is the version control of choice in the industry and has pretty powerful feature for supporting multi-developer teams.

Take the responsibility for doing this drag. It may be quite some work in the beginning, but the benefits would be manifold.

  1. The delivered software's output quality would improve. This would represent the company in good light to the client.

  2. There will be proper segregation and attribution of work.

  3. The team would improve in skillset as a whole and would gain the confidence to tackle more complex work.

  4. You'll grow as a professional gaining more skills and confidence.

  5. Good output and lesser clashes would lead to a positive and productive overall environment.

I have assumed that no one in the team is trying to lay blame unfairly on other. Just that there's an absence of a decent process and a team member could brush off any issues in the work with whatever reason they can think of at the moment.

Improve this answer
1

As a subsidiary answer to this question - I agree with the general advice "Speak up for yourself", but you should be careful to ensure that the problem is actually in your colleague's code.

Neither of you have a vast amount of time worked and my experience (both with myself and with junior developers I have worked with) is that there is a tendency to not track defects back to the ultimate source of the problem, but rather to fix symptoms of an issue rather than the root cause.

You really want to avoid a back and forth of blame here, so do be sure that you have found the area with the ultimate issue.

Improve this answer

You must log in to answer this question.

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