Do they feel frustrated, disappointed, or even don't admit at all?

  • 18
    I only write features :-) – Htbaa Feb 28 '11 at 11:24
  • Really????????? – Jervis Feb 28 '11 at 11:59
  • 11
    Love them, and tug them and pet them and call them George! – user1249 Feb 28 '11 at 12:05
  • 2
    @Thorbjørn, this is a deeply male chauvinist comment. No wonder there are so few female bugs found in this profession! :-) – Péter Török Feb 28 '11 at 13:11
  • 1
    @Péter, you should write fewer bugs and watch more cartoons! – user1249 Feb 28 '11 at 15:40

13 Answers 13


I don't know how most programmers feel about their bugs, only how I and some of my (past / present) coworkers do.

Luckily almost everyone I have worked with so far (including myself) was and is a realist: we all create bugs, it is a fact of life. The only way to avoid producing software bugs is to not write code altogether. So the important thing is not to try to avoid making mistakes, but rather to learn from our mistakes, and do what is needed to prevent them from happening again. Taken this way, mistakes and bugs can be turned into a great opportunity to learn something (about ourselves, the team, the language, the tools / frameworks used etc.) and to improve things (coding habits, communication, processes etc.).

The latter is especially important because the bugs we are worried about the most are the ones which manage to slip through to production and cause real problems to customers. This is why we have tests / code reviews / QA department etc. Whenever a bug slips through these shields, it is an obvious sign that there is a hole in our defense.

For nontrivial problems, it is a good idea to do retrospectives or post mortem analysis to recover the real root cause of the problem, so that it can be dealt with. This is explained via a great example by Joel in Five Whys.

| improve this answer | |
  • Yes. "learn from our mistakes, and do what is needed to prevent them from happening again" – Jervis Feb 28 '11 at 11:47
  • What I like to do is not just a technical post mortem but an analysis of how testing, deployment and configuration processes can be modified/extended to stop similar bugs. – biziclop Feb 28 '11 at 14:02
  • @biziclop, this is exactly what I meant, I thought this is what "post mortem" means. – Péter Török Feb 28 '11 at 14:11
  • Often it is limited to technical solutions, although the example you linked to shows how it can be taken further. (Well, even more often it is limited to shifting the blame from dev to support or vice versa. :)) – biziclop Feb 28 '11 at 14:16
  • 3
    I'd add just one thing - a way to see a bug found before a release is "it could have been found by a customer - this is a win!" - every bug the team finds is a bug the customer doesn't find. – bethlakshmi Feb 28 '11 at 15:42

I actually feel happy. When I find my own bug, I can write a test and be sure, that I will never make it again. This gives me more confidence in my own work.

| improve this answer | |
  • 1
    How about when others find your bug? – Gopi Feb 28 '11 at 12:01
  • 1
    Then I feel grateful. I can write a test and be sure, that neither I will make it again, nor anyone will be able to find it ever again. This gives me even more confidence in my work ;-) – gruszczy Feb 28 '11 at 13:05
  • It would be a miracle if one day I can see a programmer like you! :-) – Jervis Feb 28 '11 at 13:36
  • For some time now I have been thinking about migrating to Down Under, so maybe you can help me find a job there :-P – gruszczy Feb 28 '11 at 13:52
  • As an SDET, my favorite compliment from devs is "Good find!" Devs are often pretty chipper about bugs being found. – Ethel Evans Feb 28 '11 at 19:20

None of the above.

Bug are a fact of life, there's no point feeling frustrated or disappointed. The best thing to do is to admit you made a mistake, and take steps to correct it.

| improve this answer | |
  • Things are easier said than done....especially when you find the bugs in the big program in front of your boss, I presume you would change it silently. – Jervis Feb 28 '11 at 13:44

A bug is a difference from the desired behavior of the program, which happens to everybody.

The feelings involved mostly come from the amount of trouble resulting from said difference. There is a vast difference between a speling error and being woken up at 3 A.M. to be picked up by a helicopter and flown to your desk to fix it.

EDIT: Or worse, a helicopter flies your desk to you...

| improve this answer | |
  • That is true. :-) – Jervis Feb 28 '11 at 13:37
  • 2
    Really, a helicopter? I would intentionally make one just to be get a helicopter ride. – apoorv020 Feb 28 '11 at 14:39
  • @apoorv020, please do and report back how it went. – user1249 Feb 28 '11 at 16:38

There is some initial frustration that soon passes. If it affects what a user is doing and causes them to lose a lot of time, I'm more bothered by it. You'd like to think you catch those sooner.

I'd like to think I own up to all my mistakes and have little use for people who don't (not just programmers).

| improve this answer | |

Well, it really all depends on the type of bug and when it was caught.

Bonehead (ie, very simple to spot/find) bugs are fine so long as I'm the one who catches them. If I pass a bonehead bug off to the QA team, I tend to be a bit annoyed with myself.

Functional bugs are a fact of life. I don't feel frustrated or annoyed about them. Just something to accept and move on about.

I love unexpected behavior bugs when QA brings them to me. "Really, it does that? Sweet." I'm not so much a fan of them when I get a support call about them in the middle of the night though. ;)

Then there are the bugs that have lived in the code so long that they must be considered features. When you spend days debugging it to track it down and eventually kill that one stupid bug that no one else even wants to touch, I think you feel elated. You just want to tell someone when you've solved a bug like that.

But, bugs are apart of development. You can't call yourself a developer if you don't deal with bugs. Getting your code to work on time and on budget while minimizing the bug count what it's all about. :)

| improve this answer | |

Bugs are going to happen, like the coming of the tide. If there's frustration, it usually comes from a lack of understanding from my coworkers/boss that these things are normal.

However, as stupid as it sounds, reviewing code that I've recently written (wait at least 10 minutes afterwards to review) helps a lot. Writing code to anticipate strange inputs helps a ton as well (though in such cases, better to announce it rather than to sweep it under the carpet).

Or.. you could do like Htbaa and just write features. :)

| improve this answer | |

How do I feel? Realistic about a lack of perfection, but also a sense of obligation to put right anything thats wrong. That includes past employers, where if needed I'll happily be on the phone, email, whatever so that if they want to ask questions or seek assistance I'll gladly give it.

| improve this answer | |

There are 2 types of bugs really:

  • one where the code doesn't do what you thought it would do the way you wrote it
  • the other being where the code does exactly what you intended it to do but you misunderstood the requirements. (it's not a bug it's a feature!)

More of an issue is how quickly you can fix them and install a patch, and that will often depend on the development process. In an ideal system you will not need to do a full system build and install to deploy one, but instead build and install just the small component with the fix.

By the way I think most developers are happy to be "responsible" for the code they wrote and fix their bugs. It is fixing other people's bugs whilst those developers are doing the "new" coding that most developers will object to.

| improve this answer | |

Writing for myself, I feel embarrassed, but will openly admit that it's my fault. Bugs are generally avoidable.

In my current job I do very much more reviewing than coding, particularly of production code. Still, missing a problem is embarrassing and my fault. Just don't claim that it's okay to take unclear shortcuts. Attempting to review low quality code is a mugs' game.

| improve this answer | |

The only thing that really annoys me is when a bug "goes away" before I can find it. Otherwise it's just part of the job, really. While of course I try to avoid them, hunting them down is actually fun and often extremely educative.

And once you give up the concept that you own the code you've written (as you should), a positive side-effect is that you're not hurt by someone finding a bug in "your code" that much. It's still embarrassing but not that bad.

| improve this answer | |

Maybe I'm misinterpreting the tone of this thread but it seems that most people posting here are too lackadaisical with regards to bugs. As someone mentioned, there are 2 types of bugs. The ones because of misinterpreted requirements. Those are understandable.

However, the other kind, bugs in your program not doing what you thought it was supposed to do should be extremely rare. Those are the kind that show a failure on the programmer's part to their job properly. I'm getting the impression from the posters on this board that it's no big deal to release buggy code, it's just normal. Keep kidding yourselves, because it isn't normal. Or at least, it isn't acceptable at many places of business. Once or twice a year tops, maybe. But beyond that, you are a shoddy programmer and will be treated as such.

| improve this answer | |
  • I think most people here are talking about bugs coming back to you from the testing department, not being released to the customer. If you only get 2 bugs per year from testing, either they aren't doing their job, you aren't letting them do their job, or you aren't working on software complex enough to tax your potential. Writing a single function that does what you thought is easy. Writing 100,000 functions that interact perfectly is near impossible. Programmers who don't have a testing department are much more careful, but also much slower. – Karl Bielefeldt Feb 28 '11 at 16:37
  • I used to write automated tests for a military aircraft's embedded software, some of the most well-architected and reliable software out there, that spends over twice as much time and manpower on software testing than development, and still found a bug every month or so. If you think you're doing better than that, you're kidding yourself. – Karl Bielefeldt Feb 28 '11 at 16:40
  • @Karl: I work in similar/same industry as you. And I totally disagree with your premise that programmers who test their own code are much slower than those who don't. Those who don't test may send their code back for testing sooner but they end up wasting not only their time but multiple other people's time in the process before the code gets sent back to them. Also, there are 2 types of bugs, I am referring to, the requirements misunderstandings are bound to happen. That should be the majority of your problems. If you are seeing functional issues frequently then you have developer problems – Dunk Feb 28 '11 at 18:16
  • @Karl, as for finding a bug every month, I'm not saying it doesn't happen. I'm saying that you can usually trace frequent instilling of bugs in the product to the same people. – Dunk Feb 28 '11 at 18:19

I think one thing to add is that the reaction can have a lot to do with when the bug was found. I have seen defensive reactions when developers where asked to track bugs before they'd even had a chance to compile and test the code once. Needless to say, that got a strong pushback since for most folks, compiling and running code is an organic part of development. I think that every developer wants a chance to try out the code to some sane degree before they make their work "public" - so pre-check-in code changes could easily be called "development" and not "bug fixing".

Post checkin/Pre-release - I think that in most cases, the outcome is relief - whether the developer finds it themselves, or another member of the team finds it, it's a good thing to hit a bug, especially a big one, before the customer does. I have seen a strong desire in most developers to want to fix the bugs in the code they developed. This can be problematic, if you're dealing with a team where a small % of individuals wrote the code, but a much larger group is testing/debugging.

With one caveat - the "that's not a bug, it's a feature" response - there's plenty of times where a design decision (especially in UI) has resulted in some behavior that the tester finds wrong, but the coder believes is right. Convincing a developer that the "feature" is a "bug" can be a real trick, but it's doable.

Pre-release, I think the trick is to avoid the bug finding/fixing process being one of shame - it needs to be one of triumph. Every bug is an opportunity to make the code better, and it should matter who found it. If you have a culture where bugs are reviewed and attributed as a specific person's "fault" then you are likely to create a culture that shoots itself in the foot when trying to find bugs because it will be more important to to CYA than to fix the product.

The hardest can be the post-release bugs - when someone outside the technical team gets involved, it's easy for a blame war to start. The trick is to keep it focused on customer satisfaction. There's a really good example from Lexus about how a major recall was handled with such elegance, that even in the midst of a big quality problem, the company was able to wow customers. It's that sort of attitude that needs to be present - you can't think about how bad it was to have a bug -- you have to think about how gracefully you can recover.

| improve this answer | |

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