
Cognitive Dissonance in Programming - rajasegarc
http://hangaroundtheweb.com/2018/07/cognitive-dissonance-in-programming/
======
svat
This is a great article and more people should read it. I was wondering why
the sentences sound so familiar and it turns out it's heavily plagiarised (as
in, a substantial number of sentences and paragraphs are lifted verbatim from)
Gerald Weinberg's book _The Psychology of Computer Programming_ (listed at the
end as one of the "references").

Read this book; much of it is still very applicable decades later (and the
exercise of translating it into modern terms makes you think and is valuable
too).

~~~
pc86
I think by definition if it's heavily plagiarized another source it's not a
great article.

~~~
d0lph
Not necessarily, humans are pretty derivative in general.

~~~
pc86
You can be derivative without _plagiarizing_ someone else's work.

------
codingdave
It is an interesting perspective, but I find it flawed. First of all, the
author doesn't seem to understand artists, so those analogies fail. Secondly
the comment of: "But the one thing we never seem to hear* is a simple 'I
goofed again.'" tells me they haven't worked with many senior devs. I find
once devs have enough experience to not have self-esteem issues over their own
skills, there is little hesitation to admit mistakes. If we limit the scope of
the article to being about newer devs, though, the content holds more value.

~~~
renox
The thing is "a simple I made an error" is not a good enough reason: everybody
makes mistakes but why weren't they caught in UT, ET, code review? Explaining
the cause of errors and improving the process (IF necessary) is much more
interesting than "sorry, I made a mistake".

~~~
ak39
It's implied, isn't it? "I goofed up" is admitting that "I didn't test it
thoroughly".

A more interesting question, imo, is: how does the user/customer community
receive an honest admission of goofing up? Do users/customers think less of
the programmer? Or do they value the honesty?

~~~
AstralStorm
Yes, sure, because the programmer is the oracle of testing.

There are redundancies that should be set up in the development process for
this reason.

Admitting the mistake gives you nothing but low opinion of everyone involved.
(which is in itself sad) The only thing to do is to set up whole systems to
prevent them from arising again. But that is expensive so is not done.
Instead, everyone is moderately discontented with the junk they use.

~~~
AnimalMuppet
> But that is expensive so is not done.

The goal is to produce, as efficiently as possible, programs that work
adequately for their intended purpose. "Work adequately" does not mean
perfection. The optimal solution has failures in almost all directions - not-
quite-rigorous processes, not catching all bugs, not testing all scenarios,
just-barely-adequate code review, just-barely-adequate tests, and so on. To
"improve" any of those would be to make the whole process more inefficient.

That's at best, when management knows what they're doing. At worst, those
things are totally missing, and technical debt kills you later.

------
drakonka
I thought this was an interesting article, but in real life I'm not quite sure
how big the problem of programmers being unwilling to admit their own mistakes
is.

A checkin goes through many checks and eyes in which mistakes are bound to
surface, and not admitting to those mistakes is not really an option most of
the time. What's more, they are different _kinds_ of checks, so if you can
find an excuse for one thing telling you something is broken it's likely you
won't have an excuse for the next. By the time a CL goes from code review to
autotests + CI, you've potentially had to admit to a few mistakes or things
you could've done better. This happens daily in my workplace - and it's not
that these checks are foolproof and we all check in perfect code, but there
are certainly a lot of silly and not silly mistakes in both approach and
syntax which we regularly have to admit to making.

~~~
mannykannot
Cognitive dissonance appears to be a very big problem with security - people
not aggressively auditing their systems, rationalizing away concerns, etc.

~~~
CJST_
I think this has a lot to do with certain developers not knowing much about
security and not wanting to go down the rabbit hole of potential threats and
concerns. In my experience a lot of people from project managers to developers
would just rather ignore things they don't really understand (especially if
it's not causing an immediate problem).

~~~
sgarman
Especially true because customers rarely want to pay for it and when there are
issues you just sweep them under the rug and move on. Developers are the last
people we should look to blame / change if we want better security.

~~~
mannykannot
I did not mean to suggest that it is exclusively or even primarily a developer
problem, though developers do also have a role, for example in following best
practices.

------
cmsj
I wanted to be a programmer from the age of 8. I noodled around a bit in
BASIC, and then taught myself C at around 15 or 16. I was easily into my 20s
before I could even reasonably claim that I understood C. I've turned 40 this
year and even though I've written a lot of code in the last 30 years, I still
don't really feel like I'm a _good_ programmer, so I tend to always blame
myself before the libraries or the compiler or the daemons or the hardware.

~~~
cecilpl2
You can get a pretty good assessment of someone's C++ knowledge by asking them
to rate themselves out of 10, and then subtracting their answer from 10.

If they say 9/10 and they are not Bjarne Stroustrup, it's a good bet their
actual ability is close to 1/10.

~~~
Sohcahtoa82
The famous Dunning-Kruger Effect.

[https://en.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.wikipedia.org/wiki/Dunning–Kruger_effect)

------
pdkl95
> A programmer who truly sees his program as an extension of his own ego is
> not going to be trying to find all the errors in that program. On the
> contrary, he is going to be trying to prove that the program is correct –
> even if this means the oversight of errors which are monstrous to another
> eye.

From the original 1989 "Version 1.0" of The Hacker Test[1]:

    
    
        0477 Ever spend ten minutes trying to find a single-character error?
        0478 ... More than an hour?
        0479 ... More than a day?
        0480 ... More than a week?
        0481 ... Did the first person you show it to find it immediately?
    

I don't know if this is caused by cognitive dissonance of the ego, "highway
hypnosis"-style blindness from staring at your own code for too long, or
something else. Regardless, programmers have always had this problem.

[1]
[http://www.hungry.com/~jamie/hacktest.text](http://www.hungry.com/~jamie/hacktest.text)

~~~
madeuptempacct
What's a puffer train?

~~~
pdkl95
[https://en.wikipedia.org/wiki/Puffer_train](https://en.wikipedia.org/wiki/Puffer_train)

A pattern in Conway's Life that generates an infinite pattern of live cells.
(it's a pattern that drives forward across the cellular automata universe,
continuously puffing out permanently-live "smoke")

------
jm__87
This reads like someone who works only with junior devs or not very good devs.
I work on a team of senior devs who are very good and if there is ever an
issue where it could be attributable to one or more people, those people will
argue about who created the bug: "It is probably related to the code I added
yesterday, I will fix it." ... "No, I'm pretty sure it is my code. I'll take a
look".

The best way to improve is to admit to yourself that you can always be better.
Someone who thinks they are the best has no reason to improve. Anecdotally,
I've found the people who can admit their mistakes easily are some of the best
programmers I've met.

------
olavk
I don't see this is a real problem in professional development. The program
owner or customer decides whether the behavior of the program is correct or
not - not the programmer and not "the computer".

~~~
pvarangot
It's not as straightforward. I mean, I wish it would be...

POs or customers don't decide wether code is correct or behavior is correct.
The more adequate word would be that they design wether it's useful or not,
wether it's good enough or nor or wether it's on spec. Behaviour and program
correctness are Comp. Sci. disciplines and coder/engineer responsibilities.

------
RegBarclay
I freely admit I'm defective. Software development is a constant cycle of
solving problems and then solving the problems created by solving the previous
problems. Fortunately, I love solving problems.

~~~
sixdimensional
I am the same. In fact, there are whole classes of bugs that you overlook when
you don’t consider it could be a stupid mistake that you, the programmer made.

For example, if you’ve ever written a “perfectly good, you know it has to work
piece of code” and spent hours trying to prove that the compiler is wrong, or
some other crazy reason. If you are humble about it, you can more quickly
accept that you might have made a mistake and possibly find it more quickly.

This class of bug is, to me, the “it’s impossible for this code to break”
type, where it really is impossible and you made an obvious mistake. In the
rare cases where it is a serious problem and not your fault (also possible,
but quite rare), it’s important to know how to do the hard work to debug
deeply.

A skilled programmer knows both how to trust their tools, question themselves,
but also how to question, build or fix their tools if necessary. I think
patience/persistence and confidence/humility gained through experience,
combined with being creative, thoughtful, open-minded and somewhat of a
perfectionist (but not completely one!) is what it takes to code.

------
azhu
I was almost derailed by the grossly oversimplified programmer personality
dorito chart at the beginning. Personality types are merely stereotypes for
shortcutting the immensely complex network of factors underlying every
decision in every individual and should not be wielded without a deeper
understanding.

Soldier past that part and the article espouses a lamentation common in all
social situations: that people often seem to deny truth to protect the
integrity of the reality they currently grasp. The essay experiment where
groups are interviewed about the deltas in their perceptions after one group
is paid $20 to write an essay supporting a viewpoint they oppose and another
is paid $1 demonstrates this nicely. The fact that those paid $20 hold on to
their original views with more conviction seems to suggest that it is the
value people place on their past ideas (more so the efficacy of the abilities
they used to arrive to them I suspect) that precludes them from considering
the current ideas being proposed.

There is likely nothing special about the environment of programming that
gives rise to this phenomenon, and it is probably something more fundamental
to the way that humans have grown to interpret the world around them that
causes this situation. Anyone who's ever tried to have reasonable discourse
with a scouting attitude rather than soldiering one on any subject will have
noticed that at some point, some people seem to double down when presented
with clear evidence against their views.

------
forgottenpass
>But the one thing we never seem to here is a simple: I goofed again

We don't? Who is this guy working with? And keep them far away from me.

There are some good points in here about separating ego from work, and
accepting that flaws are an inevitability born from the complexity of software
development.

But it's roundabout, uses an unnecessary (and at points erroneous) line of
reasoning to get there.

It also conflates the need for "fresh eyes" in problem solving with some ego
issue. - How many times have you struggled with something, stepped away for a
moment, and come back to find the solution immediately? Or sent code out for a
code review, taken it off your mental load, then immediately spotted bugs when
you re-visit the code a day or two later?

------
watwut
I disagree with article on so many levels. Positions where you truly code
alone are rare. The issue of ownership is oftentimes issue of autonomy which
is completely normal thing to seek. I heard programmers admit mistakes
routinelly - except two rather toxic environments.

And so on.

