Being Slow to Criticise
solipsys.co.uk
Being Slow to Criticise
1–10 of 76 posts
Re: Being Slow to Criticise
#2Bother ... I've not been keeping track and I've just realised I submitted this not so long ago.
Apologies. I was prompted by the submission about "My seatbelt rule for judgment" here:
https://news.ycombinator.com/item?id=30237457
Having realised I've returned to delete the submission, but find that I can't.
/mea culpa/
Re: Being Slow to Criticise
#3Bother ... I've not been keeping track and I've just realised I submitted this not so long ago. Apologies. I was prompted by the submission about "My seatbelt rule for judgment" here: https://news.ycombinator.com/item?id=30237457 Having realised I've returned to delete the submission, but find that I can't. /mea culpa/
It's a cool read, glad you shared it again I missed it the first time (~2 month ago from what I can see).
Re: Being Slow to Criticise
#4Bother ... I've not been keeping track and I've just realised I submitted this not so long ago. Apologies. I was prompted by the submission about "My seatbelt rule for judgment" here: https://news.ycombinator.com/item?id=30237457 Having realised I've returned to delete the submission, but find that I can't. /mea culpa/
¯\_(ツ)_/¯ I wouldn't have found this otherwise and it's aligning nicely with the latest podcast from Legacy Code Rocks:
https://legacycoderocks.libsyn.com/self-compassion-with-clar...
I appreciate this double post!
Re: Being Slow to Criticise
#5So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that sounds worthy and wise, but I suspect it's actually a poor use of time on the whole.
Re: Being Slow to Criticise
#6Especially now, jammed together as we are in the global village, I suspect criticism is something we should only use defensively. Even criticism of ideas should be restricted to ideas we don't like but can't seem to avoid. Bearing in mind that if criticisms fail then perhaps the idea is a good one after all.
Re: Being Slow to Criticise
#7I delivered crap multiple times during my career. Sometimes I was forced to by external factors, sometime I was not in a good mental shape, sometime there was no time to do anything more than pile some garbage on top and duct-tape it together.
Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it functioned changed.
So yeah, I am no longer quick to judge others by the work they did especially if I don't know the circumstances. But I am of the firm opinion that we should try to be honest and say when something is garbage. It might be justified that it is garbage and the producer might not have any fault, but it's still garbage. We might not have time to take out the garbage, we might even sweep it under the rug for a while, or even permanently. Be honest though, call it what it is. How else are we going to learn to do better or appreciate the gems by contrast?
Re: Being Slow to Criticise
#8I think it is more that software is going to be "garbage" regardless (whatever that means, if the software writer disagrees with the user about what the software should do it is unclear who has the most right to call themselves correct).
A generally good software system is agnostic about the quality of its components. There are going to be bugs everywhere and it is important to guarantee outcomes. The pinnacle of this thinking is something like TCP creating a reliable connection out of fallible parts. It doesn't matter that the parts are unreliable, we get a reliable outcome because the system has realistic expectations of its components. This instance has overtones of the same thinking.
Also, Chesterton's fence is often a red herring that leads to poor practices. It is appropriate to just break things that look suspicious if the risk of failure is low. When it turns out the strange construction is needed, repair the damage done and add a comment or documentation.
Re: Being Slow to Criticise
#9So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that so…
> So how do you avoid getting nerd-sniped when something really is just bad?
This is not logic, where existence of a counterexample invalidates the general argument.
One reason for looking at even genuinely bad code is that it may express domain knowledge that you are currently unaware of.
Jon Bentley told the story of a Bell Labs researcher who found that his fast and correct algorithm for something or other had been "fixed" and "improved" so much that it was no longer efficient (a few comments may have helped here - though not necessarily - but that is a discussion for another time.)
Re: Being Slow to Criticise
#10Honestly, the software probably is garbage, because more or less all of it is. We can accept this without being nasty about it.
Decent or non-terrible software is the surprise and the exception, not the rule.