How would most programmers feel about the bugs they wrote? [closed]

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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...

Answer 5

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).

Answer 6

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. :)

Answer 7

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. :)

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.