
I’ve made a conscious effort to stop apologizing for bugs in my code - dsr12
https://blog.danslimmon.com/2019/08/02/stop-apologizing-for-bugs
======
JoeAltmaier
Switch from apologizing, to thanking the person that found the issue.
Profoundly different effect.

One is all-about-you. The other is a team-building action, recognizing the
folks who normally get a lot of grief(denial; accusations; ignoring their
input). Testers respond amazingly when they're heard and treated seriously.

It is so profound, let me tell you an anecdote. My test lead had gone to a
conference (they have them!) He was in a bar at the end of the evening,
shooting the breeze about all the type-A developers they have to deal with,
with a group of attendees.

He told the group "I have a guy in my company, I find a bug, he thanks me!
Then works closely to categorize and then fix it. No complaining; no yelling.
He just says Thank You! and gets on with it. Says I saved him embarrassment if
the bug had gone any further, and saved the company money."

Another guy in the group, from a different company in a different state, said
"I know who you're talking about. I'll write his name on this napkin, you tell
me if I'm right". He wrote my name and passed it over.

They had never met; never working the same companies at all. Were in different
places in their careers.

But I had worked with both of them. One of them, 8 years before. But still,
still I was the only developer either of them had ever dealt with, that
responded positively to a bug report.

Think about it, and then go thank your tester.

~~~
kqr
I can't believe this is rare. Well, I can, but it makes me sad. Even if you do
apologise, isn't it obvious that you want to thank and/or compliment the
person who made you wiser about your slips/mistakes? I think the entire team I
work in does, and I've only ever encountered a few people that don't. I
suspect I'm very fortunate/spoiled.

I mean, in the end, the person notifying you of your mistake didn't create
that mistake. All they did was take the state of the world from "you don't
know about your mistake" to "you are aware of your mistake". Other than edge
cases of plausible deniability, this can only be a good thing, right?

------
kinkrtyavimoodh
Why do software engineers constantly try to project that they are a special
snowflake of a profession?

Would you accept such nonsense from your plumber, or your dentist, or your
electrician?

Software engineering is one of the most fundamental building blocks of modern
civilization, and yet it continues to be so fragile because of this kind of
cavalier attitude.

Also, apologizing doesn't mean you have a moral failing. It means accepting at
least partial responsibility, and being humble about it. Any good org knows
that you don't just design your system with the hope that people won't screw
up, you need to design it to work despite some amount of screwing up. But in
either case, it is still both an individual and collective responsibility.

~~~
commandlinefan
> Would you accept such nonsense from your plumber, or your dentist, or your
> electrician?

This would be a reasonable comparison if 90% of software developers could
reliably produce bug-free code. This would be a (maybe less) reasonable
comparison if 75% of software developers could reliably produce bug-free code.
This would be a middling comparison if 50% of software developers could
reliably produce bug-free code. This is a completely unreasonable comparison
given that there have been 0 software developers ever, in the history of
software, who have been able to reliably produce bug-free code. So yes,
software development is orders of magnitude more difficult than plumbing,
dentistry or electrician(-ing?). If you think it isn't, please feel free to
jump in and prove all of us wrong.

~~~
catalogia
_Everybody_ makes mistakes, but that's no reason to never apologize.

~~~
commandlinefan
Look, if I genuinely screwed something up, sure, I'll apologize and either way
I'll fix it. But if I didn't test some corner case because the software takes
30 minutes to build, another 30 minutes to start up, and can't be run without
a live database and crashes with an out of memory error after it runs for more
than 30 more minutes and no time has ever been allocated to improving the code
quality because that's "low priority to the business" and the fix was one of
the 20 I had assigned to me in this two-week "sprint", then I don't owe
anybody an apology. If you think you can find somebody better, be my guest.

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

If I make an off-by-one error, where, other than me, did it come from?

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

If I make an off-by-one error, I could have done better.

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

It is not about shame, it is about responsibility.

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

We should all aspire to do better.

> ...They may feel ashamed if their code has bugs.

See my previous comment on shame.

About the only thing that annoys me at work is people trying to deny
responsibility for their actions (or lack of them.)

~~~
iamthepieman
> We should all aspire to do better.

aspiring to do better does not mean aspiring to write bug free code. One is a
nearly impossible goal (not over time but certainly at first and certainly
when balanced by other constraints)

> About the only thing that annoys me at work is people trying to deny
> responsibility for their actions (or lack of them.)

There's a difference between denying responsibility and apologizing.

What I do when I find a bug or someone points it out to me is say something
like

"I see that. I thought the xxx did yyy but that's clearly not the case. Now
that I think about it xxx may also do zzz, is there anything else you can
think of that I should take into account"

Or more simply. "Thanks for catching that. I'll put it in the bug tracker. Is
this a showstopper for your work?"

~~~
dnh44
I think there is also a difference between apologising while feeling guilt or
shame, and apologising and acknowledging that you’ve inconvenienced someone
without any of the guilt or shame attached.

~~~
nogabebop23
apologising as you promote is a forward-looking, positive construct; it
acknowledges a sub-optimal situation and implies you are now going to correct
it.

maybe git-blame s/b renamed git-sorry

------
jwr
I earn a living from my SaaS. I am a solo founder, responsible for everything.
I wrote all the code. My customers pay subscription fees because the software
makes their work easier (it's a B2B SaaS,
[https://partsbox.com/](https://partsbox.com/)).

Bugs are solely my responsibility: there is no one else to blame. And bugs
mean that my customers paid money for a product which did not work as intended
(certainly not as I intended it to work). I feel it is definitely right to
apologize for bugs!

I disagree with the author: if I worked at a workshop and dropped a hammer
onto my customer's foot, I should apologize. No matter what the reason: I
could be clumsy, or you could say that no one could be expected to never drop
a tool — still, an apology is in order, because I did drop that hammer, and it
made my customer's day worse.

Therefore, I _always_ apologize for bugs.

What I did, however, learn to do, and it is quite important, is not to
apologize when you are not sorry. An example is when a customer is unhappy
with the pricing, or complains about a missing feature. Many people will begin
a reply with "I'm sorry, but…", and it's the wrong thing to do. I only say I'm
sorry when I really am.

~~~
cl3misch
I think the article is talking about (not) apologizing to your coworkers, not
costumers.

~~~
dingaling
Co-workers are customers too. Everyone who has a dependency on your code is a
customer.

------
Buttons840
Here's a thought experiment.

You write some code and a code reviewer points out that you used an API
incorrectly, which you did because the documentation and test environments are
out of sync with the production API. You will, of course, modify your code to
use the API correctly, but will you "apologize"?

Now again, you call the API incorrectly, but your company doesn't do code
reviews and they just ship the code. Your code ends up causing a lot of
headache for everyone after it runs in production for a month doing the wrong
things. Do you "apologize"?

Note, what _you_ did is exactly the same in both scenerios. Should you
apologize? Are you the only one who needs to apologize? Should everyone
apologize? Like, do you all sit in a room together and go through a strange
routine where everyone around the table takes turns saying "I'm sorry".

I'm surprised by all the disagreement over this post, so I wonder what people
would think of these scenarios.

~~~
bradhe
Why is apologizing (that is, accepting responsibility) for an error that you
made--in either case, it's an error that you made--such a problem? This seems
to come from a place of deep insecurity.

Stop tying your identity to your work.

~~~
Buttons840
Alice and Bob are dating and plan to get married. They play a game in which
they receive rewards for having the same answer to questions about their
relationship.

They are asked: "Would it be preferable to serve ice-cream cake, or
traditional cake at your wedding?"

Alice writes "ice-cream cake" secretly on her answer card, but Bob is still
thinking.

After some thought, Bob writes "traditional cake" secretly on his answer card.

Both answer cards are revealed. The answer do not match, so the couple does
not win a prize.

Alice criticizes Bob, "you should have known this, we love ice-cream, we had
ice-cream on our first date!"

Bob believes he is not at fault. They argue. At one point Alice says " _stop
tying your identity to that question_ , just admit you made a mistake".

Bob still believes he is not at fault, and that he made no mistake, because it
was never within his power to be certain what Alice had written on her card.

\---

And now I ask: Is it within your power to be certain how the hardware and
software of a modern computer will act?

My point is I will never be able to be certain that my code is bug free. That
will never be within my power. I can only ensure that I follow a process that
gives a good-enough probability that my code works correctly. What that
process is, and what "good-enough" means, is largely determined by my company
and team. I do follow that process, I do what is within my power. Should I
apologize for not doing what was never within my power? Should Bob apologize
for not doing what was never within his power?

I do accept the responsibility of ensuring "my code" (however the company
wants to define it) is working well with the rest of the system now and in the
future. Apologizing is completely orthogonal to accepting responsibility.
Apologizing alone is not enough to "accept responsibility", and one can accept
responsibility without apologizing.

PS - Alice and Bob eventually learned to avoid making moral judgments
immediately in every situation.

------
Negitivefrags
So sure, bugs happen, regardless of how good you are.

But there really are some people who constantly make mistakes, and those that
rarely do.

There are people on my team where, when there is a bug, I just start looking
at diffs of what they have committed because more likely than not, they caused
the problem.

I think it's important to reinforce an attitude of trying to become better and
people who give a shit when they make mistakes tend to also be the ones who
make less of them.

~~~
erikbye
> There are people on my team where, when there is a bug, I just start looking
> at diffs of what they have committed because more likely than not, they
> caused the problem.

If you can tell the bug from looking at diffs, why was the bug not caught in
code review or by tests? Most obvious bugs should be caught this way.

~~~
lidHanteyk
In my experience, it's because Thing 1 and Thing 2 can review each others'
code, and have no compunctions about potential bugginess. Somebody else gets
to pick up after both of them, and is always outvoted during team code review.

It's like giving a minority report, honestly.

~~~
danenania
Code review also isn't great at catching the kinds of edge cases that lead to
many production bugs. Even tests only help you so much, because if you forget
about input X or state Y or api result Z while writing the code, you're likely
to forget about it when writing tests too. This is why bugs are more or less
inevitable in systems beyond a certain level of complexity that are being
actively worked on, and why engineers who think very carefully about
_anything_ that could go wrong will produce far fewer bugs than sloppy
engineers who try to use process as a safety net.

------
twic
> Through this lens, apologizing for bugs may seem innocuous. But it
> contributes to a bunch of cultural anti-patterns:

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

Imagine writing this. Imagine actually sitting down at your keyboard and
writing down that people should not be striving to write bug-free code.

~~~
flohofwoe
Doh, of course no programmer intentionally writes buggy code, yet there isn't
a single programmer in the world who doesn't write buggy code (and everybody
who claims to write 'bug-free code' is either very inexperienced or a goddam
liar).

The point is to not have a "shame culture" for writing bugs, because they are
normal part of the workflow. Instead focus on efficiently identifying and
fixing bugs (efficient debugging is an important skill that's unfortunately
often neglected).

Otherwise you end up with people writing overly defensive code, and get into a
situation like the Stalin-era airplane designers who each made their own parts
just a bit stronger then necessary because they feared ending up in Gulag or
against the wall if it was "their part" that broke. End result was planes that
were so much more heavier than planned that they were essentially useless for
the tasks they were designed for.

~~~
twic
Of course we have to accept that bugs will be written. But that doesn't mean
we shouldn't feel bad about writing bugs! Feeling bad is an excellent
motivator to write fewer bugs!

John Carmack put this better than i can [1]:

> Left to themselves, most people have a tremendous ability to ignore their
> flaws, and it hampers their growth. A bit of shame is often a positive
> motivation. I am ashamed of a lot of code I wrote last year. I have reasons
> why it is the way it is, some of which are defensible, but some are just
> “WTF was I thinking?” If you don’t have nagging bits of guilt about your
> recent body of work, it might well be a benefit for someone to point out
> problems in terms that break through your defenses.

[1] [https://www.wanzafran.com/posts/2020/shame-and-
code/](https://www.wanzafran.com/posts/2020/shame-and-code/)

~~~
flohofwoe
I wouldn't call it "feeling bad", but "feeling responsible" for your own bugs.
No finger pointing and blame games, just sit down and fix your own bugs, try
to not run into the same problem next time, and inform your team mates about
what the reason for the bug was and how the fix looks like.

But there's no need for a "formal apology" to your team either. The user might
deserve an apology by the PR department, but this shouldn't single out the
actual developer who wrote the bug.

------
h91wka
To commenters who compare work of programmer with the work of civil engineer:

There is an explanation to this discrepancy. Risk = probability of fault *
cost of fault. Programmers usually work with the data. Data has a pretty very
unique property that it is easily and cheaply copied and restored. It also
means data can be replicated more easily, which allows to build systems with
large amount of redundancy. Therefore, price of a software bug is usually
orders of magnitude less than the price of breaking something in the physical
world. This allows to drive up probability of fault parameter and allows for
much faster evolution and less regulation.

~~~
cryptonector
Replication costs have nothing to do with anything here.

The damage caused by a software bug can range from nil (even negative, since a
bug might have desirable effects) to incalculable. Consider a bug in software
used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug
in an automated medicine dispenser. Or...

You can compare the work of a programmer to the work of a civil engineer, but
it's true that it's difficult because most bugs cost little, much software is
not positioned to cause much damage if buggy, software bugs are so prevalent,
and it's so difficult to write bug-free code. But the cost of replication of
software has nothing to do with any of this.

~~~
h91wka
> Replication costs have nothing to do with anything here.

Replication is the cornerstone of fault-tolerance. When logic is written in
high-level languages with some minimal good practices, most SW bugs result in
crashes rather than data corruption, hence data replication plays important
role in protection against bugs as well as HW problems.

> Consider a bug in software used for landing SpaceX boosters... Or a bug in a
> trading platform. Or a bug in an automated medicine dispense

I specifically mentioned: "Programmers _usually_ work with the data. <...>" In
the examples you listed above software manipulates physical world rather than
pure data. I thought it was too obvious to explain.

------
old-engineer
Would you be ok with your dentist being OK with her slip-ups?

“I really should have checked the x-ray better before I extracted your front
tooth. But you know, I’m not sorry. It was an external constraint — there was
a queue of patients waiting”.

I can’t believe how low we let this profession sink. I hope in 15 years we
will look at thies era like we look at the Wild West today. Exciting from a
distance but nobody would really like to live like that.

~~~
sairamkunala
This comparison is like comparing apples to oranges.

I believe we need to get the "context" before judging any situation.

~~~
old-engineer
What I think should be common in these two cases is the attitude of a
professional towards their work.

Building software should be an engineering discipline with all its perks and
responsibilities just like building bridges. We rarely see it and it
propagates to the craftsmen who seriously believe that good quality software
is impossible to write under the slightest of constraints. Like business
pressure.

We had this ability in the past when programming was way more difficult,
tedious and error prone. Look what IBM did with their “Clean Room” approach.
I’m sure we still have it at many places but we choose to spread the myth that
it cannot be done. This call to stop apologizing is the next step towards not
even trying.

~~~
sairamkunala
> What I think should be common in these two cases is the attitude of a
> professional towards their work.

I think everyone would not deny this fact. Engineering is more of a
discipline.

But if you see things practically, this issue of "bad" code may not happen for
various number of cases. For example, unclear project requirements, use cases
etc., That is where 'context' of what happened helps to better understand the
situation.

Building bridges are not done agile and it has a learnings from decades or
even centuries. Computer Engineering is mostly agile where you push changes
based on changing requirements.

------
twelve40
This reads a bit like one of those feel-good "managers should be good to
employees! agree?" posts on linkedin. The bugs I see in PRs from even some
mature people are things like input_array[0] without checking the array for
null or size. Anyone beyond cs101 can tell you this is unacceptable and
careless, and the author likely had a "fuck it" attitude, and was in a hurry
to get back to Netflix or whatever was really on their mind.

Should we expect for them to go into a full-on dogeza Japanese kneeling bow
apology? Of course not. But there are many cases where a person glaringly
half-assed something, cut corners, quietly committed something directly to
master. And yes, this person should feel some kind of regret, or should be
brought to stop such behavior because it is extremely destructive and is
totally avoidable and caused not by overworking or accident but by persistent
carelessness and neglect, so it cannot just be cheerfully swept under the rug.

~~~
roosterdawn
Why doesn't your team have a process (integration tests, etc) that makes it
impossible to check in something like `input_array[0]` without breaking a
build? Why is it allowed to directly push to master?

How does the old saying go? The road to where is paved with good intentions?
You could engage in moralizing against "carelessness" and "neglect" and
presuming that a teammate somehow cares more about watching Netflix than doing
their job (which they presumably outperformed other candidates to even get),
and maybe that will make you feel better. You are the good, careful, model
employee, and that other one -- they're careless, slovenly, apathetic and
lazy. But if that's the case, how did they get past the door in the interview
process? If the whole company is like that, why do you work there as opposed
to a company where the bar is higher? Something does not add up. In all
likelihood, your explanation is a rationalization and not the most obvious
answer, which is that your process could be improved but it hasn't been
because such investments are not viewed by your companies executives as
improving the long term bottom line to be worth the short term investment
cost.

Take a look at history and figure out how companies in the industry have
solved this problem before by building more bulletproof runbooks, processes
and tools. These companies, as they approach enormous scale, necessarily have
to determine how to deal with employee reversion to mean. It turns out,
surprisingly, that process eats good intentions and care for breakfast. You'd
be surprised at how quickly those good intentions become useless if your
company is successful and you hit hypergrowth and scale. It's ironic that for
a profession where it is so tractable to automate away mundane or repetitive
tasks, where we study spacetime complexity in data structures and algorithms,
that we have so many practitioners that default to witch hunting and
moralizing and seem unable to apply spacetime complexity or procedural
analysis to their own software development lifecycle. I expect to see this
trend change as our still young industry continues to mature.

~~~
twelve40
Because we were a 4-person company at the time starting to hire first
employees and I realized I can't trust new people as much, so most certainly
you cannot anymore do things like input_array[0] and committing to master
because i took measures immediately after it happened, so that is not a
problem.

The problem is that the person(s) for whom I had to add these baby bumpers not
to do input_array[0] will - and has - screwed up much bigger on everything
that is slightly more complicated than that, too. Because if you are an
engineer and you don't care, then no amount of padding around you will make
you curious, careful, detail-oriented, non-lazy and capable of tackling hard
problems that life throws at you every day at a tiny startup.

------
Kapura
Shipping with bugs is not an inevitability. Bugs come from code being used in
cases other than the ones that the programmer anticipated. But it is possible
to understand how code will be used. You can test against it, either manually
or with some automated testing tool. And you can produce code that behaves the
way you expect it to every time you run it. Every once and a while you might
mistype >= as <=, but you can catch it and fix it with only a modicum of
effort.

But you first need to believe it is in your own power to write less buggy
code. If you can identify patterns that frequently produce bugs, you can try
to avoid them (e.g. copying & pasting: very buggy!). You can identify,
isolate, and document footguns and complex API. And you can be proactive in
simplifying systems when feasible to do so.

Don't beat yourself up if you accidentally have a bad commit, but don't excuse
sloppy behavior. Demand better from yourself. Don't produce garbage software.

------
yborg
This sentiment reminds me of Gerald Weinberg's observation of four plus
decades ago - "If builders built buildings the way programmers wrote programs,
then the first woodpecker that came along would destroy civilization." I was
trained as a computer engineer, and the difference between those who were
taught to approach software development as a craft and those who think bugs
are ok and it's really about feeling good about myself at the end of the day
is clear and obvious in most organizations and in the product that comes out
of them.

~~~
danenania
At the same time, if programmers had to deal with the same kinds of rigid
constraints as builders, writing a simple MVP would cost millions, and we'd
have a lot less new technology in the world.

------
Traster
Every once in a while a barrista is going to forget to you wanted soy in your
triple venti no-foam soy latte instead of whole milk. They're serving a
thousand drinks a day and the impact of getting the order wrong is tiny.

They're still going to apologize to the customer who got the wrong drink.
Because sometimes mistakes are acceptable, expected on occassion, and still
worth apologizing for when they happen. I don't always say sorry when I do
something wrong, I sometimes say sorry when what I've done has a bad impact on
someone.

~~~
PaulOlteanu
On the other hand, I (and probably a good amount of other people) say thanks
after getting our coffee, but I think it would be pretty ridiculous to expect
to be thanked for every feature I create.

------
thdrdt
Well there are multiple kinds of bugs.

You did not test it? Apologize.

You were sloppy? Apologize.

In most other cases I can agree with the author.

All I can add is that, as a freelancer, I always explain (like they are 5)
what went wrong. My customers don't care about the details but they like it
when they know I made an effort of creating good software (bugs included).

~~~
aeno
> You did not test it? Apologize.

Not on every case. I once had a customer who literally removed the "Testing"
part of my offer because it seemed to expensive to him.

As testing often takes a considerable amount of time I do list it explicitly
in an offer and don't "hide" it in the numbers for the other tasks.

~~~
catalogia
Imagine if electricians let their customers opt out of electrical code
compliance...

------
malikolivier
As a manager, I've always striven to apologize for my errors. I do agree that
errors are unavoidable and are bound to happen. That's why I actually never
cared at all whether programmers apologize for bugs. Fixing bugs is also part
of the software development process after all.

However, I've always believed an apology is important to show humility to my
team mates. As a manager, I do not want to appear entitled. Of course, as soon
as the error is uncovered, we should prioritize it and fix it. But I do not
believe that proceeding to fixing an error is orthogonal to apologizing for
it.

We are trying our best to build a company without a guilt culture. In such a
position, is apologizing a bad move as a leader? What would you do?

~~~
lenzm
I'm a manager and I appoligize if it was a stupid mistake made from
carelessnes. Apologize if you did something you wouldn't want other people
doing.

I think context matters too. The industry you're in (what are the consequences
of bugs) as well as the part of the codebase (presentation or data integrity)
change the acceptability of bugs.

------
brujoand
If you fuck up I don't really care about an apology. I want to know:

    
    
      1. How will you fix it? 
      2. How will you prevent it from happening again?
    

An apology, in my head atleast, is for when you have caused emotional distress
to someone and there isn't much you can physically do to fix it other than to
convey how you now feel about what you have done. When you make a practical
mistake an apology is implied by you fixing it.

~~~
twic
There are perhaps two parts to an apology. One is an acknowledgement that you
did something wrong, and that you should not have done it. The other is a sort
of ritualistic, performative (in the original sense!) use of language that may
make someone feel better. This is the difference between:

"I made a mistake when i dereferenced that null pointer"

and:

"I'm sorry i dereferenced that null pointer"

I absolutely agree with you that the ritualistic part is pointless, and
perhaps harmful if it is performed instead of actually fixing the problem (see
also "thoughts and prayers").

But i wouldn't want to stop doing the acknowledgement part.

~~~
zeroimpl
I wouldn’t refer to the first stage as an apology, it is simply an
acknowledgement.

I very rarely apologize for a bug at work. I don’t expect others to apologize
to me either. Apologies should be reserved for personal/relationship things,
like forgetting to invite somebody to a meeting.

------
Angostura
He says that this is a fallacy:

> It reinforces the idea that any one person or piece of code can be blamed
> for a given failure.

Why is that a fallacy?

~~~
ithkuil
Probably because there is always a bigger picture: culture, process (e.g.
testing, code review, time pressure, feature centric performance metrics).

Surely, the person making the mistake is the proximal cause for a given bug,
and surely all other things being equal personal attitude matters (i.e. a more
careless person is going to make more mistakes), but if you zoom out to the
big picture you see other responsibilities and more importantly you see
opportunities for improvement that vastly exceed the playoffs of "just putting
more care" into each commit.

~~~
Angostura
Understood. Thanks for the explanation. I have to say I don’t intuitively like
the position, because taken broadly you could conclude that no-one in an
organisation is ever personally responsible for their actions, because some
system should have prevented the mistake. This feels wrong

~~~
ithkuil
Indeed, it does feel wrong because it is, technically, wrong.

The intent of a "no blame culture" however is to find a new sweet spot on the
myriad of tradeoffs an engineering organization does, as an many paradigm
shifts we do, it is accompanying with a certain amount of bullshit-sounding
maxims meant to be thought provoking and dislodge the readers from their
suboptimal local maximums.

------
yxhuvud
No, I'm not going to stop taking responsibility for my actions.

------
dilap
I am in complete disagreement with this sentiment!

If you're using my code and hit a bug, I am, genuinely, sorry. The goal state
is craft software that works properly. That is not an unreasonable goal!

Of course, mistakes will happen, but you _should_ be sorry, and you should
think about what would have avoided it (better programming methodology? better
testing?).

Aim to create high-quality software that delights its users!

~~~
zeroimpl
Apologizing and feeling sorry are two different things. If you say sorry for
every bug, the word will lose meaning.

~~~
dilap
I'm not like on my knees begging for forgiveness, but I feel regret that an
unfortunate thing happened.

To me it's a similar situation to if I, say, accidentally spilled your drink;
something of that nature.

(I guess different people could attach different amounts of significance to
the word. To me it simply means, "I feel sympathy that this unfortunate thing
happened, and I wish it had not.")

------
freediver
Bugs are the responsibility of the process that brought them there. In most
cases it is shared responsibility.

Why doesn't your dentist mess up 1 out of 5 interventions? They have gone
through years of strict training and there are giant liabilities in place.

In development? A lot of self-taught developers, who can always jump to a next
gig because of never-ending demand. This sets up the scene for a totally
different scenario - never-ending stream of bugs.

If you want your team to have less bugs, then as a manager make sure you have
a process in place that optimizes for that. Start with your hiring process and
add requirements for code quality practices. Then build a process that
includes strict commit guidelines, documentation, code reviews and QA process.
Most importantly, add time to estimates that ensures all of the above is
checked properly. After all that is in place, define in a clear way some sort
of liability for bugs.

Your dentist goes through all of that, why not your developers doing arguably
equally important work?

~~~
i_haz_rabies
In absolute terms there's a lot more CS degrees working dev jobs churning out
bugs. Self-taught devs can be great. Degree devs can be shit.

I mostly agree with the rest of your post.

~~~
freediver
May be - may be not. Would you trust your dental work to a self-taught
dentist? What makes developers a special case? I am agnostic to it and
genuinely curious.

------
ilaksh
I agree about not apologizing for bugs.

But I disagree about it being something special to leaders.

And the way he says it, makes it sound like maybe he thinks leaders shouldn't
apologize in general. Which I think is a fairly common belief that leaders use
to justify not admitting they made a mistake. And is 100% different from not
apologizing for bugs. Since as he points out, bugs are not mistakes, they are
a normal part of development.

When the manager makes a significant mistake it's not like a bug, it's a poor
judgement that probably affected everyone. And sometimes if it's a very
negative affect then an apology is warranted. But at least, it's usually
necessary to acknowledge when you had people going in the wrong direction.

------
fredsted
I think it's worth acknowledging over your customers that the bug has caused
them lost time or other kinds of issues. Whether you do that with an apology,
it doesn't really matter, but I know I'd personally feel better when a vendor
emphasizes with me.

Something you definitely don't want is to sound like it's an inconvenience for
you that they're reporting bugs. Bug reports are extremely helpful and you
should be grateful that they're taking the time to report them to you.

~~~
erikbye
> I think it's worth acknowledging over your customers that the bug has caused
> them lost time or other kinds of issues.

As a company, by some PR representative, yeah, sure, maybe, but individual
developers should not apologize.

~~~
fredsted
I guess it depends. As a solo entrepreneur, I do it all the time, because I
care about my customers.

Working at Instagram, probably not, since it wouldn't be my job to handle
support.

------
andersource
It's interesting how polarizing this article is. After zigzagging several
times while reading the comments I just think that reality is more nuanced
than "never apologize" or "apologize", and it simply depends on the context.

It seems to me that most comments with a strong opinion (including the
article) have a specific scenario in mind, involving assumptions about the
dev's intentions to write good code, the bug's effect, how easy it would have
been to avoid the bug, and who is this person we're considering to apologize
to (coworker / manager / customer / QA who found the bug). In some situations
apologizing feels right, in others it doesn't, so there's not much sense in
generalizing from a single scenario to the general case.

I think ultimately it comes down to matching expectations: almost all people
involved in software development expect bugs. The question is how much effort
do they expect me to put into reducing the quantity and severeness of those
bugs. When I go to a dentist I expect them to make every possible effort to
avoid harming me; generally this is not the expectation of software developers
going about their day. A feature that takes one hour with reasonable effort at
ensuring quality could easily take a day or a week if you make _every possible
effort_ to ensure it is bug-free. Different pieces of code (at different
times) could have different amounts of impact, so it takes a wider
understanding of the code's context to decide how much effort I'm going to put
into chasing bugs. When in doubt, I match expectations with the relevant
stakeholder(s). Then the situations where apologizing feels right are either
those where I didn't meet the expectations, e.g. I was in a hurry to push so I
didn't take the time to properly test and I should have known better (not very
frequent); or situations where I didn't take the time to properly match
expectations (though sometimes that's on the other party, but it takes two to
match expectations).

One other thing regarding responsibility - I think that taking responsibility
and apologizing are different things. Sure, you can take responsibility by
apologizing, but there are other ways too. When something breaks in my
apartment and I call my landlord, they (usually) take full responsibility and
make sure the problem is fixed, but so far they never apologized, and it would
feel funny if they did.

------
KhalPanda
A lot of the replies and analogies here are interpreting this as a business-
consumer apology. Of course if a business has disrupted a customer's
experience through buggy software they should issue post-mortem/apologies/etc.

But I read this as though the author is saying apologies to fellow teammates
shouldn't be necessary, which I do at least in part agree with.

------
bryanrasmussen
I wish I could find that one guy I worked with about 19 years ago that tried
to load an ActiveX component in his VbScript running in Netscape and send him
this article, true he never apologized - but I just want to make sure he
doesn't feel bad about never apologizing.

------
abete
Bugs categories are also important. My project and my leadership was destroyed
when a non-technical wanna-be "operation" manager without experience in
software development, started to see only bugs and reduce all development to
bug fixing. Some "bugs" are in reality wrong or misunderstood requirements.
Some are missing features. Sometimes the joke "it's not a bug it's a feature"
is real. Sometimes "bugs" are edge case we didn't want to solve immediately,
until the edge case it's not edge anymore. I think what is dangerous it's
seeing ONLY bugs, focus dev ONLY on bugs. Shift a little the point of view
from bug fixing to software evolution.

------
nogabebop23
Maybe as a Canadian we've eroded the stigma with apologizing. Saying you're
sorry is not about taking blame or responsibility; this attitude is what stops
an overly litigious society from saying "sorry".

It's an empathetic response that says "I am putting myself in a different
context and trying to understand how it feels". This makes it perfectly
appropriate to say "I am sorry" a lot more than we do: when learning about a
friend's bad-luck circumstances, a customer's poor experience or adding a bug
to your code.

------
zerpelin68
This touchy-feely analytical approach to not worrying about emotional and
exemplary damage resulting from not knowing any better is hard to take. The
self importance of not worrying is conducive to the sloppy industry the NG
works in. No one can be held responsible for not knowing what they should know
because they aren't expected to know it. They are semi-functional components
in a dysfunctional machine.

------
eximius
This seems to conflate ownership/responsibility with admitting a flaw in
yourself.

If someone points out a bug, I say thank you. People make mistakes. I am a
person. I make mistakes. This is not controversial, it is expected. We should
still strive to avoid them and are allowed to be annoyed with ourselves when
we make them, but it doesn't make us bad people.

------
gwbas1c
The biggest career lesson that I've had is that 80% of development is testing.

Should you apologize for bugs? No. But if you're doing professional quality
work, (as opposed to prototyping or researching,) a large portion of your time
(as a developer) should be writing automated tests (like unit tests) to test
the code you write.

------
jon889
Maybe don’t apologise for it, but I definitely think it’s useful to
acknowledge if it was your code as it removes an awkwardness around it.
Obviously this doesn’t have to be done for every little bug but if there’s a
discussion around one then owning it can help.

------
jes5199
there is an assumption here that I want to challenge: that code can be
correct.

Code is _always_ a flawed approximation of an ideal system. You can move bugs
around, but you cannot get rid of them: software _is_ bugs.

------
chadlavi
People were apologizing?

My instinct is always more like, "oh, nice catch!"

------
diebeforei485
Particularly for entry-level folks: if your code passed code review, it means
others didn't catch the bug either.

The company could apologize to customers if needed. But it would be insane to
make the individual developer apologize to customers.

------
joesb
While I agree with not "blaming" people for the mistake as if it's their fault
as a person. I disagree with all of his reasoning and the action he choose not
to do in this case.

I also take the position of "criticizing the idea/code, not the people" when
it comes to other people's work. I rarely have a problem with criticizing
myself.

Especially when it comes to "your" own code. You should be able to apologize
for your mistake.

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

You can be attributed to your action. If you can be attributed to the good
things in your work, then you can be attributed to bugs. Unless you are
claiming that you have no control what so ever about how your code turns out,
at which point, what are the different from you and a typewriter?

The thing is, you can be attributed for an instance of error. You can be
blamed for the error you did. But you should never be categories as "the
error".

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

Yes. There are instances that I could have written it better.

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

I take the approach and culture of "be strict with yourself but be kind to
others". When I talks about other people's bug I always criticize the bugs
itself and talks about problem and process in general without tying it to
them. But when I talked about my code, I will also express what I could have
done better or what is the pros and cons of my coding decision.

The thing is there's different between people striving to better themselves,
and people blaming others for not being better.

You should strive to be better, while at the same times not being a snob or
looking down on other for not being perfect.

In every day's life there's no permanently good people or bad people. There's
bad action that people do. You should still be able to attribute a certain
instance of event to a person. You just don't have to hold grudge and judge
them forever based on it.

I am probably reaching it here, but I feel that the author is the kind of
person that can't take criticism of his idea well because he feel that his
idea is himself.

Your idea and action is yours. But your idea and action is not who you are. If
you think it is yourself, then you become blindly defensive and either never
acknowledge that you did it, like the author did, or never change.

