Live data from Hacker News

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

blog.danslimmon.com

141–150 of 194 posts

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

#141
post #111

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…

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.

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.

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

#142

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…

This thought experiment is flawed. It assumes the only variable worth considering are the actions of the individual. The reality is that we apologize all the time for doing something that, done one day previously or to a different person, would not have been a problem at all.

We're typically not apologizing for the act itself, we're apologizing for the effect it had. We don't mean "sorry for writing code with bugs in it", for example. We mean "sorry the bugs in the code caused you problems."

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

#143

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…

Try working in military applications, aerospace, tax software, medical devices, banking. Making one mistakes can affect the fates of hundreds if not millions. It's way more responsibility and risk than the job you quote.

By the way. A dentist gets to try on fake tooth before drilling a real tooth. They actually don't have a choice, that's part of the mandatory training. Doctors gets to train on real people too, medicine schools go to great length to procure bodies for training purpose.

In programming, one would be lucky to get any sort of test environment.

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

#144

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

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.

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

#145
post #111

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…

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.

Cognitive Behavioural Therapist (CBT) Dr David Burns has moved away from saying "sorry" to patients and clients who are upset by something during therapy sessions; he says apologising with "sorry" is such a problem because it's a too-easy meaningless platitude that people throw out without any thought and expect it to act to immediately silence the other person's upset without any further discussion, and the person on the receiving end of "sorry" knows this common use and expects it to be a cheap dismissive silencer which they can't respond to, so apologising isn't the same as accepting responsibility, apologising without accepting responsibility is dismissive and trivialising, accepting responsibility is better without it. That apologising doesn't add to understanding, it takes away from it.

Accepting responsibility is understanding the other person's reasons for hurting, which means listening to them.

Apologising is trying to make the other person to stop hurting, and stop them from talking anymore so you don't have to hear more or spend more time on it.

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

#146

Earlier quoted context omitted.

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

This is a great question. To me, the only answer is (as I believe you're alluding to) "who" is at fault is not relevant when compared to "what" is at fault. In this case, the problem is the lack of proper systems level integration testing, and neither Alice's nor Bob's code in isolation, and the "who" that ends up being at fault should be the management chain of command that allowed the state of things to allow such a scenario to occur. As management decides to want to prevent such embarrassing and costly blunders, they should resolve to invest more in the process and tooling that prevents such situations from being possible.

Of course, it is also possible for management to shirk such responsibility and push that responsibility (without corresponding process ownership) onto the ICs. It's quite common in low performing organizations.

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

#147

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…

This thought experiment is flawed. It assumes the only variable worth considering are the actions of the individual. The reality is that we apologize all the time for doing something that, done one day previously or to a different person, would not have been a problem at all. We're typically not apologizing for the act itself, we're apologizing for the effect it had. We don't mean "sorry for writing code with bugs in…

The though experiment illustrates that the same actions in different circumstances can have different results. What part of that assumes the only variable worth considering are the actions of the individual? The central point is that, as you say, whether or not we apologize depends on the circumstances.

I agree that you have to consider more than only the actions of the individual. I believe, if there is fault, it lies with not just one person, but also the circumstances. In cases where the circumstances are determined by management, company culture, legacy code, etc, the fault lies with many if not everyone. Thus, if one should apologize, then everyone should apologize.

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

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

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

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

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

#150

Earlier quoted context omitted.

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.

I don't think anyone is argue for one instead of the other.

Why not a little bit of both? Can we not think about system and data driven improvement while also at the same time apologize for our mistake?

Post reply on HN