6 ms·

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

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

vb6sp6 7y ago
> About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.) Someone once said "There is a difference between 10 years of experience and 1 year of experience 10 times". The best developers I know always take responsibility and try to do better.
- ignoramous 7y ago
  The point being made is how bugs invoke an automatic admission of guilt in developers, and absence of which shouldn't be seen as not taking responsibility, especially when tranches and layers in the system (built over the years, say) could have made the entire debugging and development process cumbersome, uneasy, unconventional, unyielding, dense, exhausting, and frustrating. Taking responsibility might involve any among: - documenting the behaviour for future maintainers. - writing tests. - identifying and pushing the management to fix technical debts. - digging up the root-cause to fix deeper flaws, if any. - advocating for saner development and deployment practices. - ...
iamthepieman 7y ago
> 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 7y ago
  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 7y ago
    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
- mannykannot 7y ago
  > aspiring to do better does not mean aspiring to write bug free code. One is a nearly impossible goal... Hence 'aspiring' not 'achieving'.
dnh44 7y ago
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.
- mannykannot 7y ago
  You make a valid point here. In a toxic environment where guilt and shame are tools of oppression, you do not, in practice, have the option to be candid.
aeturnum 7y ago
>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 https://en.wikipedia.org/wiki/100_metres
- mannykannot 7y ago
  >>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... If you are blindly following direction to that level of detail, are you a programmer or a typist? Maybe there will be corner cases like this, but they do not invalidate my point. > Tyson Gay is only behind Usain Bolt in the 100 meter world record by 0.11 seconds. This is not a comparable situation. For one thing, off-by-one errors are not off-by-0.11 errors, though the difference is more significant than that. > If it's about responsibility, then there should be a process for understanding why engineers end up writing bad code. Of course, and there is no shame in that. Part of answering that question, and in becoming a better programmer, comes from acknowledging and understanding the mistakes we make (this is an important part of aviation safety, and the last thing an instructor wants to see is a student who has a tendentious excuse for every lapse.) And no-one is responsible for things they cannot control, unless they set them in motion themselves, or ignored the likelehood that they could happen. >> We should all aspire to do better. > I agree! Yes! this is the most imprtant point - and there is no shame simply from falling short.
rurp 7y ago
> 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.
jt2190 7y ago
> It is not about shame, it is about responsibility. Assigning personal attributes (responsible/irresponsible) like this is a sub-optimal strategy for improving human performance. It conflates what a person does with who they are. What a person does is malleable, and their performance can be improved with teaching, practice, better techniques, etc. Experienced teachers understand this and avoid turning a discussion about correctness into a discussion about character, as it's counter-productive, and reinforces the narrative that performance is based on innate character, not on hard work.
- mannykannot 7y ago
  > It conflates what a person does with who they are. It is not obvious to me that there is anything very wrong with this. In particular, I think it is rather more reliable than going by what they say.
jodrellblank 7y ago
> If I make an off-by-one error, I could have done better. "I did not do X, therefore I could have done X" seems clearly false. How do you know you could have done better? And if you could, why didn't you? And if you actually didn't, what does it usefully mean to say you "could have"? You "could have" done better but didn't, does that imply you didn't want to do better? Is that what you want to communicate - you wanted your code to be worse - because that isn't in your favour either. You wanted to do better and didn't do better, that's back to implying you wanted to but weren't able to, i.e. you couldn't.
- mannykannot 7y ago
  > How do you know you could have done better? Because it was an error! I could have done better by doing the thing that fixed the error! I am not a religious person, but the Lord save us from those who have an excuse for everything.
  - jodrellblank 7y ago
    So answer the rest of my questions - you could have, you didn't. Why not? a) you actively wanted to produce bad code. b) you couldn't have. c) other? > the Lord save us from those who have an excuse for everything. Lord save us from people who think self-flagellation is at all useful or beneficial to anything. It's status-signalling and nothing else, you're in hypothetically the same situation as someone else (having made a mistake) but you want to claim to be superior because you're feeling the most bad about it?
    - deleted 7y ago
      [deleted]
    - mannykannot 7y ago
      c) I made a mistake first time around. In this post [1] we see you arguing that everyone makes mistakes, yet here you seem unable to recognize it as the obvious answer to your question. Perhaps not coincidentally, a failure to be semantically consistent is a common root cause of programming errors. > So answer the rest of my questions - you could have, you didn't. Why not? As a rule, I try to avoid responding to utter nonsense, though I must admit to breaking that rule in this thread. [1] https://news.ycombinator.com/item?id=22975241 https://news.ycombinator.com/item?id=22975241
say-vagnes 7y ago
Well put. I am amazed at the replies to your comment. My thoughts are, it's all about accountability. Good development and, more broadly, learning, rely on effective feedback loops. "Did it work? Y/N and why?" repeated over and over. When you blur accountability in an effort to be empathetic, it messes with this loop. You've changed the definition of "it" to not be fully what was in your control, and then as a result don't have a clear action you can take to do better next time. This, to me, is how you wind up with 10 1 year experiences. To summarize, even if a bug is only 10% your fault, be accountable for it, because that's a clear signal towards something you can improve. Accountability doesn't mean falling on some sword, you can also own improving the things that lead you to make this mistake. The difference is, you're taking action to improve things, versus distributing blame (which I find often leads to "what can you do" type mentalities, leaving all the broken things there for the next unlucky person)

vb6sp6 7y ago

> About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.) Someone once said "There is a difference between 10 years of experience and 1 year of experience 10 times". The best developers I know always take responsibility and try to do better.

ignoramous 7y ago
The point being made is how bugs invoke an automatic admission of guilt in developers, and absence of which shouldn't be seen as not taking responsibility, especially when tranches and layers in the system (built over the years, say) could have made the entire debugging and development process cumbersome, uneasy, unconventional, unyielding, dense, exhausting, and frustrating. Taking responsibility might involve any among: - documenting the behaviour for future maintainers. - writing tests. - identifying and pushing the management to fix technical debts. - digging up the root-cause to fix deeper flaws, if any. - advocating for saner development and deployment practices. - ...

iamthepieman 7y ago

> 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 7y ago
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 7y ago
  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
mannykannot 7y ago
> aspiring to do better does not mean aspiring to write bug free code. One is a nearly impossible goal... Hence 'aspiring' not 'achieving'.

dnh44 7y ago

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.

mannykannot 7y ago
You make a valid point here. In a toxic environment where guilt and shame are tools of oppression, you do not, in practice, have the option to be candid.

aeturnum 7y ago

>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 https://en.wikipedia.org/wiki/100_metres

mannykannot 7y ago
>>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... If you are blindly following direction to that level of detail, are you a programmer or a typist? Maybe there will be corner cases like this, but they do not invalidate my point. > Tyson Gay is only behind Usain Bolt in the 100 meter world record by 0.11 seconds. This is not a comparable situation. For one thing, off-by-one errors are not off-by-0.11 errors, though the difference is more significant than that. > If it's about responsibility, then there should be a process for understanding why engineers end up writing bad code. Of course, and there is no shame in that. Part of answering that question, and in becoming a better programmer, comes from acknowledging and understanding the mistakes we make (this is an important part of aviation safety, and the last thing an instructor wants to see is a student who has a tendentious excuse for every lapse.) And no-one is responsible for things they cannot control, unless they set them in motion themselves, or ignored the likelehood that they could happen. >> We should all aspire to do better. > I agree! Yes! this is the most imprtant point - and there is no shame simply from falling short.

rurp 7y ago

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

jt2190 7y ago

> It is not about shame, it is about responsibility. Assigning personal attributes (responsible/irresponsible) like this is a sub-optimal strategy for improving human performance. It conflates what a person does with who they are. What a person does is malleable, and their performance can be improved with teaching, practice, better techniques, etc. Experienced teachers understand this and avoid turning a discussion about correctness into a discussion about character, as it's counter-productive, and reinforces the narrative that performance is based on innate character, not on hard work.

mannykannot 7y ago
> It conflates what a person does with who they are. It is not obvious to me that there is anything very wrong with this. In particular, I think it is rather more reliable than going by what they say.

jodrellblank 7y ago

> If I make an off-by-one error, I could have done better. "I did not do X, therefore I could have done X" seems clearly false. How do you know you could have done better? And if you could, why didn't you? And if you actually didn't, what does it usefully mean to say you "could have"? You "could have" done better but didn't, does that imply you didn't want to do better? Is that what you want to communicate - you wanted your code to be worse - because that isn't in your favour either. You wanted to do better and didn't do better, that's back to implying you wanted to but weren't able to, i.e. you couldn't.

mannykannot 7y ago
> How do you know you could have done better? Because it was an error! I could have done better by doing the thing that fixed the error! I am not a religious person, but the Lord save us from those who have an excuse for everything.
- jodrellblank 7y ago
  So answer the rest of my questions - you could have, you didn't. Why not? a) you actively wanted to produce bad code. b) you couldn't have. c) other? > the Lord save us from those who have an excuse for everything. Lord save us from people who think self-flagellation is at all useful or beneficial to anything. It's status-signalling and nothing else, you're in hypothetically the same situation as someone else (having made a mistake) but you want to claim to be superior because you're feeling the most bad about it?
  - deleted 7y ago
    [deleted]
  - mannykannot 7y ago
    c) I made a mistake first time around. In this post [1] we see you arguing that everyone makes mistakes, yet here you seem unable to recognize it as the obvious answer to your question. Perhaps not coincidentally, a failure to be semantically consistent is a common root cause of programming errors. > So answer the rest of my questions - you could have, you didn't. Why not? As a rule, I try to avoid responding to utter nonsense, though I must admit to breaking that rule in this thread. [1] https://news.ycombinator.com/item?id=22975241 https://news.ycombinator.com/item?id=22975241

say-vagnes 7y ago

Well put. I am amazed at the replies to your comment. My thoughts are, it's all about accountability. Good development and, more broadly, learning, rely on effective feedback loops. "Did it work? Y/N and why?" repeated over and over. When you blur accountability in an effort to be empathetic, it messes with this loop. You've changed the definition of "it" to not be fully what was in your control, and then as a result don't have a clear action you can take to do better next time. This, to me, is how you wind up with 10 1 year experiences. To summarize, even if a bug is only 10% your fault, be accountable for it, because that's a clear signal towards something you can improve. Accountability doesn't mean falling on some sword, you can also own improving the things that lead you to make this mistake. The difference is, you're taking action to improve things, versus distributing blame (which I find often leads to "what can you do" type mentalities, leaving all the broken things there for the next unlucky person)