Stop apologizing for bugs

Look out, honey, ’cause I’m using technology

Ain’t got time to make no apology

The Stooges, “Search and Destroy”

For the last year or so, I’ve made a conscious effort to stop apologizing for bugs in my code.

Apologizing for bugs is very tempting. I used to do it a lot. When my code was involved in a failure that screwed up a coworker’s day or caused a user-facing problem, I’d say “Whoops! Sorry! I should’ve thought about that.”

The motivation for apologizing is sound: you want to do your best for the team. In principle, you could have prevented a problem if you’d just done something slightly different. Through this lens, apologizing for bugs may seem innocuous. But it contributes to a bunch of cultural anti-patterns:

  • It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case.
  • It gives the impression that, when you wrote the code, you should have written it better. This is a counterfactual that rarely holds up to examination.
  • It positions shame as the correct emotion to feel about bugs in your code: if you were a better engineer – a better teammate – the bug wouldn’t exist.
  • If you’re a more senior engineer on your team, the effects of these anti-patterns are magnified: people see you apologizing for bugs, so they think that they should be striving to write bug-free code. They may feel ashamed if their code has bugs.

Even if you don’t intellectually believe any of these fallacies about bugs, the act of apologizing reinforces them. Your teammates can’t know what you really believe; they can only know what you say and do.

Everyone knows that all code has bugs. Code is written under constraints. Deadlines. Goals other than quality. Imperfect knowledge of the future. Even your own skill as an engineer is a constraint. If we all tried to write perfect, bugless code, we’d never accomplish anything. So how does it make sense to apologize for bugs?

This rule I’ve made for myself forces me to distinguish between problems caused by constraints and problems caused by my own faults. If I really think I caused a problem through some discrete action (or lack of action), then that’s something I’ll apologize for. But if I wrote code that got something done, and it just so happens that it didn’t work in a given situation, then I have nothing to apologize for. There was always bound to be something.

Make a resolution not to apologize for bugs. Especially if you’re in a leadership position. It’s a simple way to tweak attitudes about mistakes and failure in a positive way.

15 thoughts on “Stop apologizing for bugs

  1. Dan

    Sorry to nag – just wondered if you still use Oscar? Have done a search of the blog and not found a reference to it. All best!

  2. Pingback: Stop apologizing for bugs - Proxap

  3. cmdr2

    Thanks for the different viewpoint! I’ve recently been in a position of having to respond to a failure in a very public situation at high scale. The root reason for the failure were things not really in my control. Obviously, going ahead, there are things I plan to do now, to monitor those “external” factors more closely, but they’re almost things like the weather. Despite monitoring them, they’ll do the random thing very often.

    Anyway, I still felt it important to apologize to people for their bad experience, more as a way to empathize with them, and not for flogging myself in public. A bad user experience (depending on the product) can result in users being embarrassed at their work or family/friends, or just feeling disappointed. So I felt it important to atleast express empathy with their disappointment, regardless of whether I was to blame or not. Obviously not every product probably justifies this.

    Before any public response, first I had to be clear with myself that I didn’t really need to feel guilty, since the root cause was really something I have almost no control over, or I’d ever considered would be a problem. So once I felt consistent internally (and it wasn’t easy), the next step was to atleast address what the aggrieved people felt, without being unfair to myself.

    There are certainly some really entitled brats out there, and it’s hard to feel any empathy for them. But they’re probably the vocal minority. In general, as a customer, if something caused pain and problems, would I prefer the product owner respond with empathy, or with coldness?

    I don’t think we’re really disagreeing here at all, I’m probably making a tangential point here. I’d be interested to hear your views on this, would certainly help improve my response policy going ahead 🙂

    Thanks!

  4. Pingback: HackerNews weekly summary [2] | Damian Mąsior

  5. I write code for living (10+ years) and I consider myself semi-introvert semi-extrovert. I try to give honest feedback on the code reviews I do and that sometimes can sound brutal. Now, if you are someone who has done a sh[*]y job of coding because you have no time to write a good working code, chances are I am spending longer to review your work. I rather spend that time doing my own work but if I am reviewing your work and you are non-apologetic about your bad code, I am going to take it as someone who does not acknowledge his/her mistake. I don’t care if you say “sorry” or not.. but I do want to hear.. “I will do better next time”. I am not here to compensate for your shortcomings. I don’t get paid for reviews. I get paid for writing my own new features.

    And, the more humane we keep the interactions, the more natural it is, the better. I don’t want to work with robots. I rather have some fun with my colleagues.

    1. Dev

      But, but, code reviews ARE (or SHOULD BE) part of your job. Expecting people to be flawless feature-writing robots is just fanciful.

    2. vrp

      Total nonsense. You can’t even read this blog and understand its intent, and you claim to be doing some great code reviews? Please read it again. You are wasting my time by forcing me to review your comment.

    3. stone

      @amitkcoo you just sound like a selfish bigot. well at least everyone is entitled to their opinion. You’ve writing codes for the past 10+ years, does that mean all the codes you wrote perfectly clean without blemish?
      the idea of code review is to have a neat optimised approach to a problem. when you have a better cleaner approach to someone else code, should the person apologise to you for it?
      Or wasn’t it from experience you learnt?

  6. Pingback: Я приложил сознательные усилия, чтобы перестать извиняться за ошибки в моем коде — My Blog

  7. Pingback: Fiz um esforço consciente para parar de me desculpar por erros no meu código - Mídia Nossa

  8. Shon Fargessen

    One wise person said if you mix regret and foolishness you get (self-)blaming as result.

  9. No, no and NO. What programmers need to understand is that bugs they leave can cause a pain or even a loss of life in real world. And I’m talking not only about NASA or other programmers. Even trivial bug in a filesystem could erase someone’s life work, or a bug in a database could leave a company out of business. A bug in a bank reporting application could get someone in trouble regarding their credit, etc. etc.
    It is understandable that no code is perfect and most bugs are left without malice, but in the end it is developers job to write code as perfect as possible, so it makes perfect sense to apologize if you didn’t do your job well. And if developer don’t have time to write good quality code it is his job to ask for help or to demand deadlines which can be met.
    BTW, the same nonsense arguments “… under constraints. Deadlines. Goals other than quality. Imperfect knowledge of the future. Even your own skill as an … is a constraint. ” can be applied to any role, not just IT. So you are suggesting to get rid of apologies all together?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s