1. 44

  2. 25

    What you can apologize for: production problems or ramifications due to the bug. Developers can choose empathize with their users: “I’m sorry for the hours of debugging you had to do, that sounds miserable. Thanks for bringing this to my attention”.

    1. 4

      “I’m sorry for the hours of debugging you had to do, that sounds miserable. Thanks for bringing this to my attention”

      I’d say that’s not really an apology, it’s just an empathetic statement.

      If I’m not acknowledging fault, then it’s not an apology. Usually one has to express what you’re going to do (or would like to have done) differently, too.

      1. 2

        I agree to a point. I find that “Thanks for all the effort you put into running this to ground. That sounds miserable. Sorry you had to do that. Here’s how I think we might reduce that in the future.” wears much better than “Sorry you had to do all that debugging. Thanks…”

        I’m not saying I’d avoid apologizing/empathizing at all… I just think it’s more effective to bring the “thanks” front and center.

      2. 13

        I agree with not apologizing for bugs in a professional setting, but on this particular quote, I beg to differ:

        If we all tried to write perfect, bugless code, we’d never accomplish anything.

        Software should be perfect. We should all try to write perfect, bugless code. It’s OK to accomplish this via an iterative process. But that is a completely valid and laudable goal. I’d go so far as to say if a given organization does not have this goal, then it is contributing to the modern-day dystopia of brittle, under-performing code that haunts our everyday lives. One example: Iowa 2020 Caucus Disaster

        1. 6

          We should all try to write perfect, bugless code. It’s OK to accomplish this via an iterative process.

          Definitely agree. This is a core reason we try to create better more robust tools and even programming environments too. It’s OK not to be perfect, but for me personally at least it feels deeply questionable for that not to be the aspirational goal in the limit.

          1. 2

            Yes, the coders of the Iowa Caucus app should clearly have refused to deploy it. Maybe. Probably.

          2. 12

            My philosophy of bugs was really affected by Deming’s common versus special causes of variation. In a stable setting, bugs would be in statistical control, and they’d be coming in at a constant rate. Telling programmers to be more diligent isn’t going to reduce the number of bugs because statistical control implies the whole system is involved here. The system of work is what causes bugs, so we minimize the number of bugs by changing our tooling and processes.

            1. 8

              I agree you shouldn’t apologise as an individual, but for very different reasons. Bugs are caused by cultural and process issues that are extremely pervasive in all forms of engineering, but especially in software. Yes, writing bug-free software is extremely difficult. No, it is not impossible. Engineers should not be complacent about the inadequate state of things. We should be striving to build a better future.

              1. 7

                This is based on a narrow view of what an apology is: it views an apology as an admission of guilt. However, apologies serve a broader purpose: they have the social function of communicating that you would have preferred for the thing you are apologizing for to not have happened/existed/been the case.

                Example: if I do something that inconveniences my wife, even if I couldn’t have known it would, she appreciates it a lot if I say “Sorry”. Not because it was my fault and I should have prevented it, but because I thereby acknowledge it inconvenienced her and express a desire not to have done that; a shared wish for the counterfactual world in which the inconvenient thing wouldn’t have happened. Some are now thinking “That shouldn’t be necessary” or “That goes without saying” and to them I say “Good luck in your relationships” :).

                1. 6

                  Taken one step further, don’t apologize for anything. When you constantly apologize for something the meaning of those apologies start to mean less and less. Then when you actually fuck something up and need to apologize, everyone has already heard it 1000 times.

                  1. 4

                    I’ve had several conversations with non-technical friends along these lines: replacing “bugs” in this article with “mistakes” provides a good approach to life in general.

                    Not apologising and not caring differ. When I make mistakes, I try to help the people affected, and I assess what I might change in future. I still apologise, but I aim to do so less often and save apology for particularly significant occasions.

                    1. 3

                      Distinguishing between when you should and shouldn’t apologise for your work doesn’t only help the culture and practice of working in a team (or simply behind a product) but also helps making an apology more valuable. People who care and are motivated do strive to get better because of an aspiration, the will to become better, and are not intemidated of making mistakes - they know its a part of the process of understanding your job better, the requirements, the product and facing an aggressive and challenging environment. And they should treat the same to their coworkers with respect and understanding. But if something does happen because of being easy on the trigger, or negligence - an apology is appropriate and sheds light on what kind of mistakes could’ve been avoided due to discipline and practices… When people put their ego away and work with others to push everyone forward, it becomes a natural habitat.

                      1. 3

                        Don’t need to apologise. But you should acknowledge. No excuses about requirements or how development doesn’t match production. Acknowledge, fix and move on.