Dealing with one of those. You know the guys. 4-6 years of experience and gets some feedback from a user about a bug they swear doesn't exist. I've seen the bug personally happen, and yet, out of fear I think of being seen as bad, they refuse to admit it. How have you dealt with this and what can I do? In the past this person has reacted almost violently to suggestions like this, using company resources in an attempt to persecute. I can't get them fired, but I can teach them a lesson.

closed as unclear what you're asking by Dawny33, Lilienthal, Jim G., gnat, David K Nov 23 '15 at 13:32

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Do you have any sort of bug tracking process in place? – Brandin Nov 23 '15 at 12:05
  • the lesson is simple: let them close the bug, let the user escalate it, and let management know that the colleague refused to properly investigate the user issue... nature will then take its course. – gbjbaanb Nov 23 '15 at 16:19
  • 2
    You should never try to 'get someone fired' or 'teach them a lesson' - Jesus, we're all just here to work and feed our families. Educate the guy on the right way to do things, and create some proper processes to follow to log and investigate bugs. – Jon Story Nov 24 '15 at 1:05
  • 1
    @JonStory Or he/she could simply take a screen shot or steps to repeat the bug. For example if the email said, "I don't see any bug" you could reply with, "Here are the steps to reproduce it and the screenshot." – Dan Nov 24 '15 at 15:43

I've seen a number of this type of developer over the years. They're always right, no matter what, and arrogant about their ability.

In truth, there is only one way to deflate them, and that is to prove that they're wrong.

...a user about a bug they swear doesn't exist. I've seen the bug personally happen...

If the bug is seen, then you need to reproduce it. Prove that the issue exists and make sure the steps to do so are well documented in your bug tracking system. This will firstly formalise the bug, and secondly make it apparent that the developer isn't quite as perfect as he may seem.

his person has reacted almost violently to suggestions like this

Have you feared for your personal safety? Have others? If this person is acting in an unprofessional manner like this, then it needs to be flagged with your manager. Keep records of when and where, under what circumstances. This is important as this evidence may be necessary at a later date if an incident occurs.

Really, the best advice I can give is to just track everything, both of bugs being denied and bad behaviour. If he's arrogant for no good reason, then he'll come unstuck. If he's got behavioural issues to go with it, then you absolutely need to document every time you are fearful and why.

  • 2
    Hi Jane, from experience reproducing a bug is often 90% of the work. So reproducing a bug for someone who apparently is too arrogant or lazy to do it himself is a huge waste of time for the poster. – gnasher729 Nov 23 '15 at 11:58
  • 4
    @gnasher729 Oh, I agree that tracking down a tricky bug can take a lot of time, but if the OP knows the bug is there, they would be remiss not to report it and how they got it. A documented bug is harder for a lazy developer to ignore :) – Jane S Nov 23 '15 at 12:01
  • @gnasher729: OTOH, if the bug has not yet had reproduction steps determined for it, then it should not yet be on your bug tracking system and there is not yet any reason to insist that the bug insists. So, in short, it's not "a waste of time"; it's your job. – Lightness Races in Orbit Nov 23 '15 at 15:19
  • @LightnessRacesinOrbit i think the point is that it isn't the OPs job but rather that of the colleague who swears its not a bug. Nobody likes doing allt he grunt work (reproduction in dev env) so someone else can come along and dot he fun part (the coding) to fix it. – gbjbaanb Nov 23 '15 at 16:16
  • @gbjbaanb: No, it isn't that guy's job. When a bug is raised, proof of its existence must be provided. I agree it would be nice if this guy didn't jump to "I don't believe you" every time, but it's not his responsibility to disprove himself. – Lightness Races in Orbit Nov 23 '15 at 16:31

On one hand, there are bugs that are very hard to reproduce.

On the other hand, with 4-6 years he is a newbie, and I know from experience that whenever I was sure that a bug couldn't possibly exist, it did. There's the first rule of debugging code, which apparently he hasn't learned yet: "Whatever you know about this bug, it's wrong". That applies first of all to his statement "this bug cannot possibly exist".

In many cases, reproducing the bug is the hard bit. Once you know how to reproduce it, the fault in your code is often either obvious or very easy to find. So if he claims that a bug isn't possible, tell him from me that he just isn't a good developer.

And there's the second rule of debugging: "The problem is there because there is something wrong with the code". That's an absolute essential. People who don't understand this rule waste everyone's time including their own by claiming a bug is not possible, it is a hardware problem, it is a compiler problem, it's just gremlins that don't like you, instead of concentrating on finding and fixing the problem.

  • Nothing here I disagree with, +1 :) – Jane S Nov 23 '15 at 12:04
  • "if he claims that a bug isn't possible, tell him from me that he just isn't a good developer." Not wonderful advice. – Lightness Races in Orbit Nov 23 '15 at 15:20
  • 1
    "The problem is there because there is something wrong with the code" If you'd ever actually worked with hardware, you'd know this is not always true. We've had five bugs closed as invalid last week because the problem was caused by badly soldered RAM. – Lightness Races in Orbit Nov 23 '15 at 15:20
  • @JaneS, of course there is something to disagree with. Many bugs happen through poor understanding of requirements or flat out poor requirements, not just because "there is something wrong with the code." – Amy Blankenship Nov 23 '15 at 17:17
  • 1
    @LightnessRacesinOrbit /true. Just wasted the entire last week finding the bug in the firmware of a magnetic stripe reader, just to find out, that our consumer has been botching around and made one pin loose. – Sempie Nov 24 '15 at 11:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.