Live data from Hacker News

I’ve made a conscious effort to stop apologizing for bugs in my code

blog.danslimmon.com

121–130 of 194 posts

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#121

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

I think in some ways the author is on their way to making a greater point about making mistakes without quite hitting the nail on the head.

Guilt and shame are the enemy of responsibility and those who seek to inflict guilt and shame are toxic to any organisation. They encourage those who are focused on maintaining an image of never being wrong while punishing those who seek to better themselves and obviously make mistakes as they grow.

I managed to remove everyone from my life who inflict a guilt or shame (luckily not any family members) and life has got way better since then both personally and professionally.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#122

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

I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how Toyota created the kanban process and implemented the andon cord. It's strange and probably not useful if it's based around assigning guilt. But if it's based around trying to uncover a root cause in process or system deficiency and solving that, then no, it…

Maybe I've been watching too many Star Trek reruns, but the thought comes to mind: "Blame is irrelevant, apologizing is irrelevant."

I've been part of such retrospectives, and no blame is given, and no apologies are given. There is no hesitation to lead the investigation into "your own code". "Your code" might end up being what needs to change, but it was not alone in causing the fault in the entire system.

Another though experiment (stripped of all moral judgement):

Alice writes some code which runs as part of a larger system for 10 years. No problems are identified in the system.

Bob writes some code. After Bob's code is integrated with the rest of the system, problems are identified in the system.

Changes are made to Alice's code which resolve the problems.

Who is at fault? You probably find it hard to identify who is at fault without knowing more details. You need details so you can form your own personal moral judgments. Perhaps a better question is: Can we ever objectively identify who is at fault? And does it matter?

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#123

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

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

Could have come from confusing documentation on the appropriate bounds, could have come from an unclear exit condition for the loop, could have come from contradictory requirements that had no real solution. That you're the agent at the end of a chain doesn't release the chain from responsibility.

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

People often miss targets by small amounts. Tyson Gay is only behind Usain Bolt in the 100 meter world record by 0.11 seconds[1]. Is that all on Tyson not working hard enough, or are there maybe other factors?

> It is not about shame, it is about responsibility.

If it's about responsibility, then there should be a process for understanding why engineers end up writing bad code. Of course it can be that the engineer made a mistake, but it can also come from many other factors. Assuming that the person who wrote a bad line of code should "take responsibility" puts the cart before the horse in building a good process.

After all - it's the compiler that emitted machine code that did the wrong thing. Maybe the compiler is the real villain here.

> We should all aspire to do better.

I agree!

[1] https://en.wikipedia.org/wiki/100_metres

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#124

Earlier quoted context omitted.

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

You have got to be kidding me. Do you even understand the consequences of making mistakes in other fields? In some cases an apology isn't even enough. In some cases imprisonment and an utterly ruined career are the result of mistakes. So the idea that apologizing shouldn't happen as a programmer is complete rubbish.

> In some cases imprisonment and an utterly ruined career are the result of mistakes

This is quite an exaggerated point; the number of people imprisoned for making mechanical, civil, or electrical engineering errors is very close to zero in the US.

I think more programmers have actually been charged than any other field, although I can't quote a statistic to back that up.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#125
post #67

Earlier quoted context omitted.

I think the important point is to let go of ego issues. A bug is a technical problem, how do we address a technical problem? By being level-headed and not playing the blame game. Being sorry doesn't add any relevant information and generate a strange atmosphere, like admitting a moral failing really. Any matter of substandard performance is better dealt by the management, well outside the scope of bug fixing.

Refusing to accept responsibility for your own errors is more an ego problem than the alternative.

No, elaborate insistence on repentance rituals, shaming, and ideologies of "personal responsibility" over systems thinking and data driven improvement is all about ego.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#126

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

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

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.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#127

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

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

I have seen countless instances, both in and out of software development, where a manager:

1. Explicitly told an employee to rush through a task too quickly, and that some bugs/cleanup/whatever would be OK and handled at a later time.

2. A short time later freaked out because the rushed task was not done perfectly.

Of course only terrible managers behave this way, but there are a lot of terrible managers out there. In these sorts of environments simple errors are often ubiquitous.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#128

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

> You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation is out of sync with the actual API. You will, of course, fix the mistake, but will you "apologize"? If it was feasible for me to catch the erroneous API behavior through testing, before code review, I would see no reason to not apologize. Your second scenario is not even remotely ambiguous, o…

It's always feasible to find a bug by testing. Even in the case where your code relies on some accidentally convenient behavior that might disappear in the next version of the API, you could have reimplemented the API as a stub in your test from only the documented interface. But it's often more efficient to find bugs through code review.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#129

Earlier quoted context omitted.

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

Orders of magnitude harder? Get over yourself. You sit in a comfy climate controlled office with perks like free food and drinks, gyms, entertainment, etc. You make a mistake, and a program doesn't run correctly. The horror!!!! An electrician, plumber, or dentist makes a mistake and that could result in someone getting hurt or even someone to die. A dentist doesn't get to run a dev/staging/prod environment before dri…

GP meant "harder" in the "it's possible to get things "perfect"" sense, not in the "leads to a more challenging professional life" sense.

Re: I’ve made a conscious effort to stop apologizing for bugs in my code

#130
post #76

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…

I think a part that needs to be considered in the comparison is also the concept of safety factors.

Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles.

Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field.

Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.

Post reply on HN