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!
> 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.
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)
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.
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.
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.
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?"
maybe git-blame s/b renamed git-sorry
Hence 'aspiring' not 'achieving'.
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.
"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.
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.
> 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?
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.
> yet here you seem unable to recognize it as the obvious answer to your question.
I'm the one who is insistent that it was a mistake and that people make mistakes. You're the one insisting there's some loophole where you can both get it wrong and feel good that you could have got it right, at the same time. I'm saying that it's your position which is utter nonsense, a meaningless double-think designed to make you feel good, which reflects nothing about the world.
Like a kid saying “I ate ten hot dogs and threw up, but I could have eaten fifteen!” - nobody believes it, you couldn’t, you’re trying to save face and get credit for eating fifteen hotdogs without actually doing it.
Now, whether you can do better in future is a different matter - I’m not saying you can’t do things to avoid that mistake happening again, or learn from experience, or get better.
This is bizarre. Where on earth did you get the idea that I am arguing that one could have not made a mistake? The whole issue is about one's attitude and behavior after having done so.
I am not going to consider anything else you write here until you clear up that mystery, which seems to be the root of your confusion.
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.
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.
- ...
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.)