[HN Gopher] Operant Conditioning by Software Bugs (2012)
___________________________________________________________________
Operant Conditioning by Software Bugs (2012)
Author : dceddia
Score : 21 points
Date : 2021-01-25 18:15 UTC (4 hours ago)
(HTM) web link (blog.regehr.org)
(TXT) w3m dump (blog.regehr.org)
| csours wrote:
| > The second reason I wrote this piece is that I think operant
| conditioning provides a partial explanation for the apparent
| paradox where many people believe that most software works pretty
| well most of the time, while others believe that software is
| basically crap. People in the latter camp, I believe, are somehow
| able to resist or discard their conditioning in order to use
| software in a more unbiased way. Or maybe they're just slow
| learners. Either way, those people would make amazing members of
| a software testing team.
|
| I think this is one of the big differences between junior and
| senior software developers. You can see juniors get very
| frustrated with bugs because the code they delivered was
| 'working'. Seniors realize that software only works within well
| defined parameters - and it's only a matter of time before you
| find another parameter that you did not define well enough
| beforehand.
|
| I also think there's a hierarchy of software implementations:
|
| Working As Expected (by the user)
|
| Working As Designed (by the designer/lead)
|
| Working As Intended (by the programmer)
|
| Working As Implemented (by the programmer)
|
| [this is somewhat tongue in cheek]
| l0b0 wrote:
| > I think this is one of the big differences between junior and
| senior software developers.
|
| This may just be the curse of knowledge, but as a senior
| developer I would have to disagree. I've thought software was
| crap as long as I've used it, and I believe I can find a bug
| (or at least what I would consider a bug) in about five minutes
| using any software. Part of the problem is there are so many
| dimensions in which the software can be crap:
| unapproachable/overengineered, lacking in features, badly
| documented, inconsistent, slow, unstable, etc. The software
| could absolutely be some of the best in the world and still be
| terrible on one or more axes.
| dang wrote:
| If curious see also
|
| 2018 https://news.ycombinator.com/item?id=16863233
|
| 2015 https://news.ycombinator.com/item?id=9822637
|
| Apparently not discussed at the time
| danaliv wrote:
| _> Anyone who has been in a tech support role has seen the
| bizarre cargo cult rituals that result from unpredictable
| failures._
|
| I remember when "zapping the PRAM" was the solution for
| everything on classic Macs. (Maybe it still is?) It was a truly
| bizarre group-level tic. Literally any issue would be met with a
| stampede of experts bearing the magical key combo Cmd-Opt-P-R. I
| doubt anyone even knew what was _in_ PRAM, but by god zapping it
| would fix your computer and neuter your cat.
| chubot wrote:
| I referenced this article in a blog post last year. It's not very
| hard to tickle obvious bugs in bash's completion system.
|
| However even though they are things you would do pretty
| frequently like echo $(basename <TAB>
| echo `readlink <TAB>
|
| I somehow wasn't aware of them. I suspect that's because I have
| been using bash for something like 15 years and was TRAINED not
| to type those things!
|
| _Oil Uses Its Parser For History And Completion_
|
| http://www.oilshell.org/blog/2020/01/history-and-completion....
| jodrellblank wrote:
| See the Penrose Triangle illusion[1]; what if the operant
| conditioning makes people who see the gap in the triangle joint
| find some workaround to jump over it, and maybe that training in
| some piece of software aligns people to see the whole triangle
| and not see the gap at all. Is there any research into whether
| people trained on some software consider it more reliable than
| people thrown into it?
|
| In the 2018 thread someone writes[2] " _but if I sit down with a
| new user for an hour, they discover all the bugs I knew about and
| a few I didn't! But an hour of someone's time is hard to get_ ";
| but the internet is full of people clamouring to give feedback
| about your code, desperate for someone - anyone - to listen. An
| hour of someone's time is hard to get, are you kidding me? I've
| spent hours challenging myself to find hundreds of nitpicks in
| something, for free, just because they asked. What did they do
| with it? Ignore it. More zeitgeisty look at the "MS Teams is
| slow" complaints, thousands of upvotes on UserVoice, one reply
| "we're working on it". Stuck that way for years.
|
| It's not hard to get feedback, you don't _want_ feedback because
| you don 't have time or interest or spare effort or motivation to
| fix all the bugs, you have more fun things to do - more
| interesting, higher priority, more defensible. It's way better to
| have forum users pass around the Chinese Whispers of their
| grandfather's command line which he found on a BugZilla comment
| on an unrelated issue, which came from a mailing list, which came
| from an unsourced email from an internal chatroom where they
| found it in a fossil,,, than it is to fix that edge case. Users
| telling each other to clear the PRAM and run "sfc /scannow" and
| "chmod 777 -R" and "setenforce 0" costs you nothing.
|
| [1]
| https://cdn.dribbble.com/users/6205/screenshots/5556008/penr...
|
| [2] https://news.ycombinator.com/item?id=16866679
___________________________________________________________________
(page generated 2021-01-25 23:02 UTC)