last day (14 days later) » 

02:07
152
Q: How to deal with a coworker who blamed me for the bug that was his fault

RyanI’m relatively new at a job, but have established myself as the “guy” when it comes to a certain web service we use. Our own website integrates with the service. I don’t really work on the site, just with the service. Today we had something of a show stopping issue that resulted in users of the ...

Is this person a superior? Do you have a project manager of some sort?
I'm assuming you have the code under source control and can show the offending error as being checked in by this person?
Create a conference call explaining the issue raised. Go through what you did, and then say something along the lines of "the issue was traced to X. I'm not sure who's done that, could (the person who being a passive aggressive a clown) explain it?"
You mention poor communication, have you considered whether your communication and/or documentation on how the webservice functions is unclear, and that this may be a contributing cause to why the developer integrated to it incorrectly?
+1 for "abso-posi-f***ing-lutely" because it made me chuckle, plus you know, this is such a common problem. Devs can get snippy. So should be a very useful question to have on the workplace.
02:07
I agree with the answers (keep communications blame-free). But you should also make an effort to genuinely forgive the guy, in private communication, tell him you can understand why he thought the problem was on your end and discuss if there's anything that can be done to improve the situation. This gives him an opportunity to apologize (and feel better about it) and gives you some grace/slack/benefit-of-doubt if a future problem happens to be your fault.
Being devil's advocate here. Based on your comment here, his complaint was focused on your conduct (i.e. that you were communicating poorly). You're response is focused on the code. Those could be two separate issues. You've already pointed out that the original error was his fault, but that doesn't excuse you for poor communication (if, in fact, you were communicating poorly). Just another perspective.
@Jeff yeah but this doesn't mean he has to blame somebody for their communication when they actually commit bugs... even with poor communication I expect all the programmers involved to not deploy bugs in production. This means testing.
@mickburkejnr That response would make you a "passive aggressive clown".
@DerekElkins No, it'd make me passive aggressive. He's the clown for being wrong.
@Cris depends on what could be the root cause of the bug being committed to the code-base. As someone said, if the backend service isn't well documented, it is sometimes hard to code a frontend that will send proper requests to the backend. Not saying this is the case here, but sometimes the bug isn't really traceable until deployed (and there, it depends on how much tests they have. If they only have unit tests, but no integration, for instance, such a boo-boo would be understandable)
02:07
@mickburkejnr It's the being passive-aggressive that makes you a clown (or more, a child). Everyone makes mistakes including mistakes about their mistakes. Even you. God forbid when the "clown" explains X it turns out it is correct. I've been in plenty of scenarios where the subject matter expert end-users initially thought my code was wrong, only to change their minds later.
Its not totally uncommon for people to get snippy even when they are the cause, its something that you have to learn to deal with at work and as a human in general. Though you should make sure you don't end up with the blame from a political point of view.
Sneak onto his computer, install a global grammar checker on his machine, make sure it's in effect for whatever text editor he uses to edit source, and set it to autocorrect == to =. Sit back and watch as hilarity ensues. (disclaimer: this is a joke, don't actually do this :-P)
TL;DR can be the first paragraph (my pref), TL;DR can be the last paragraph (daft imho), but TL;DR should never be the second to last paragraph especially outside of the emphasised part.
If one person's error can cause a show-stopping issue, then the problem is with the process, not with the developer.
Just a heads up: make sure what you fixed was the root cause and not something that just happened to expose a different problem.
02:07
On our team, we developers have tried to stop using “you” or our names when describing portions of code. This prevents accusations or what could sound like accusations. We all work on the app together and we frequently work on code that another may have worked on a month or 6 ago. Making it personal when we see a need or difference can only be divisive, so removing that made it fairly friendly.
Plenty of (invalid, dangerous, often illegal) suggestions can be found here theregister.co.uk/data_centre/bofh
OP, sooooo what's happened since??
You're worrying about nothing. It's a non-issue in software.
@Jeff If the questioner was communicating poorly, then that would make two...

last day (14 days later) »