Mixing
How to deal with new coder arrogance? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-2
down vote
favorite
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.
communication
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
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.
suggest improvements |Â
up vote
-2
down vote
favorite
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.
communication
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
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
suggest improvements |Â
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
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.
communication
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
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.
communication
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
asked Nov 23 '15 at 11:16
Sayed Kooshesh
8
8
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.
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
suggest improvements |Â
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
2
2
Do you have any sort of bug tracking process in place?
– Brandin
Nov 23 '15 at 12:05
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
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
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
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
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
@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
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
8
down vote
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.
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
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
 |Â
show 3 more comments
up vote
4
down vote
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.
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
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
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
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.
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
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
 |Â
show 3 more comments
up vote
8
down vote
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.
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
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
 |Â
show 3 more comments
up vote
8
down vote
up vote
8
down vote
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.
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
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.
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
answered Nov 23 '15 at 11:47
Jane S♦
40.8k17125159
40.8k17125159
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
 |Â
show 3 more comments
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
2
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
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
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 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
@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
@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
@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
 |Â
show 3 more comments
up vote
4
down vote
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.
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
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
suggest improvements |Â
up vote
4
down vote
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.
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
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
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
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.
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
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.
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
answered Nov 23 '15 at 11:56
gnasher729
70.9k31131222
70.9k31131222
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
suggest improvements |Â
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
Nothing here I disagree with, +1 :)
– Jane S♦
Nov 23 '15 at 12:04
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
"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
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
"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
@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
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
@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
suggest improvements |Â
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