5 ms·

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 t

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.

catalogia 7y ago
> 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, of course I'd apologize if I caused other people that much hassle.
- kragen 7y ago
  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.
bradhe 7y ago
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 7y ago
  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.
- jodrellblank 7y ago
  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.
roosterdawn 7y ago
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 doesn't seem strange to me. You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue. Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue. In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.
- Buttons840 7y ago
  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?
  - roosterdawn 7y ago
    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.
colinmorelli 7y ago
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."
- Buttons840 7y ago
  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.
  - colinmorelli 7y ago
    Apologies for my misunderstanding (hah, very topical for the post). The way it concluded made me interpret it as if you were trying to suggest that the person's actions were the same, and thus the scenarios were the same.
    - Buttons840 7y ago
      Hmm. I guess I kind of did mean that. Rather, I meant to make people question whether the individuals actions were all that mattered. Another example: If my wife wants me to invest in stocks and I do so after doing a lot of research and preparation, and that stock goes down, do I apologize? Do I apologize because of things that happen after and independent of my original actions? Or maybe my wife should apologize? Maybe nobody should apologize? How much depends on the stock market? Out of our control and comprehension.
benibela 7y ago
With web APIs there are also a lot of things that happen, even when the API is used correctly. The HTTP request can time out. The firewall of the user has blocked the request. The server might be turned of for maintenance. The server might have an expired certificate.

catalogia 7y ago

> 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, of course I'd apologize if I caused other people that much hassle.

kragen 7y ago
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.

bradhe 7y ago

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 7y ago
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.
jodrellblank 7y ago
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.

roosterdawn 7y ago

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 doesn't seem strange to me. You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue. Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue. In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.

Buttons840 7y ago
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?
- roosterdawn 7y ago
  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.

colinmorelli 7y ago

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

Buttons840 7y ago
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.
- colinmorelli 7y ago
  Apologies for my misunderstanding (hah, very topical for the post). The way it concluded made me interpret it as if you were trying to suggest that the person's actions were the same, and thus the scenarios were the same.
  - Buttons840 7y ago
    Hmm. I guess I kind of did mean that. Rather, I meant to make people question whether the individuals actions were all that mattered. Another example: If my wife wants me to invest in stocks and I do so after doing a lot of research and preparation, and that stock goes down, do I apologize? Do I apologize because of things that happen after and independent of my original actions? Or maybe my wife should apologize? Maybe nobody should apologize? How much depends on the stock market? Out of our control and comprehension.

benibela 7y ago

With web APIs there are also a lot of things that happen, even when the API is used correctly. The HTTP request can time out. The firewall of the user has blocked the request. The server might be turned of for maintenance. The server might have an expired certificate.