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.
Dan Slimmon 
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!
Pingback: Stop apologizing for bugs - Proxap
Excuses, excuses, excuses…
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!
Pingback: HackerNews weekly summary [2] | Damian Mąsior
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.
You’re a jerk off
+1
But, but, code reviews ARE (or SHOULD BE) part of your job. Expecting people to be flawless feature-writing robots is just fanciful.
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.
@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?
Pingback: Я приложил сознательные усилия, чтобы перестать извиняться за ошибки в моем коде — My Blog
Pingback: Fiz um esforço consciente para parar de me desculpar por erros no meu código - Mídia Nossa
One wise person said if you mix regret and foolishness you get (self-)blaming as result.
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?
This is bar far the most terrible thing I read this year. Which is a loaded statement, considering that year 2020 is annus horribilis.
Your shameless, defeatist and apologetic advocacy for sloppy coding is absolutely unacceptable. All bugs are authored and bug authors must rise to the occasion, accept ownership and with it accept consequences of their actions.
Anyone writing software code has the responsibility and accountability to make sure no bugs get released to customers. Failing to do so is grounds for dismissal.
People who shrug and claim that bugs are inevitable and that they have no way to ensure their code is not buggy are definitely in the wrong line of work. They should immediately start looking for other career options, because the field of engineering is not for them.
If you think this blog post is advocating in favor of sloppy coding you either didn’t read it or didn’t understand the point it’s making. This article is not about coding practices. It’s based on the assumption that you will inevitably make mistakes. It advocates against apologizing when that day comes.
Claiming that anyone can go through life as a programmer (or any other profession for that matter) without making a single mistakes is, of course, ridiculous.
Foregoing the apology does not prevent one from accepting ownership of the bug (that would require you to lie about how it originated and no one here is arguing in favor of lying to your employer) nor does it stop you from accepting the consequences.
You are conflating two very different things here. A developer can still feel a strong responsibility towards his employer or customers without apologizing for bugs. Apologizing also does not prove that a developer feels responsibility towards his employer or customers. Feelings of responsibility and accountability have no bearing on this discussion at all.
Apologizing has no tangible benefit, it only serves as (self-)punishment in the form of self-flagellating humiliation. Unless you value this sort of punishment, there is no reason to apologize since doing so actively delays taking responsibility (i.e. damage limitation, implementing preventive measures).
This is just trolling. If I ever have to work with you, prepare yourself.
I don’t completely agree. I think it is fine and well-mannered to make a simple, non-grovelling apology for the effects of an error. This is no different to apologising for accidentally bumping into someone in the street. It reinforces being kind to one another. An apology can mean “sorry, we will learn from this”, not only “sorry, I’m an idiot and everything has to be perfect”. Apologies have the tangible benefit of making other people feel better.