8 ms·

Cognitive Dissonance in Programming

112 points by rajasegarc 8y ago

deleted 8y ago
[deleted]
drakonka 8y ago
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 8y ago
  Cognitive dissonance appears to be a very big problem with security - people not aggressively auditing their systems, rationalizing away concerns, etc.
  - kazagistar 8y ago
    Agreed, but a lot of automatic security scanning is really heavy on false positives, which can be extra obnoxious for people.
  - CJST_ 8y ago
    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 8y ago
      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 8y ago
        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.
- ZainRiz 8y ago
  Right. The author seems to talk about typos and simple bugs in the code, but every programmer makes those on a regular basis and no way anyone could deny such a bug when it's pointed out to them. This cognitive dissonance seems like it may be more applicable at a higher level, when talking about design flaws in the system. There the programmer can actually come up with excuses for their "issues". For example, if someone complains "but your design won't scale to 1 million customers" the programmer might reply "come one, we need to be fast" or "we won't need that kind of scale until years from now"
pdkl95 8y ago
> 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
- bena 8y ago
  I'd say it's way more the hypnosis reason. You stare at it and stare at it and get so used to it that you don't notice that you needed a > where you have a <.
- howard941 8y ago
  Reading through fn [1] was fun at first but now I feel very old and frail.
- madeuptempacct 8y ago
  What's a puffer train?
  - pdkl95 8y ago
    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")
- beat 8y ago
  I think of that as a flaw of perception, not cognitive dissonance.
RegBarclay 8y ago
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 8y ago
  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.
svat 8y ago
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).
- mannykannot 8y ago
  I was about to say the same; the phrase "The programmer comes down the hall with his output listing and it is very thin..." certainly shows its age. The message, however, is just as relevant now as it was then.
- huntie 8y ago
  I just stumbled across Weinberg's book at the library yesterday and thought that it looked good. I'm glad to hear that it is.
- pc86 8y ago
  I think by definition if it's heavily plagiarized another source it's not a great article.
  - d0lph 8y ago
    Not necessarily, humans are pretty derivative in general.
    - pc86 8y ago
      You can be derivative without plagiarizing someone else's work.
  - svat 8y ago
    Depends on your definitions. If someone makes a copy of the Mona Lisa and claims it as their own, does it stop being a great painting? (Or if you don't think the Mona Lisa is a great painting, replace with whatever you think is.) In fact given what I can tell of the author(s) in this case, we should be grateful it's so heavily plagiarized; the less they plagiarized (and the more they inserted their own content), it seems the worse it would be. :-) ---------------------------------- BTW I took a look at the article again, and it contains solely of two paragraphs picked up verbatim from Wikipedia, followed by the remaining paragraphs each verbatim from book. The only changes I could detect were: 1. where the book mentions "Starting with the work of the social psychologist Festinger", the article has "Starting with the work of the social psychologist Leon Festinger" with a link to the Wikipedia article for him 2. the article introduces random bolding of various words 3. where the book says > There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple... the article says (turning the correct "hear" into "here") > There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple... Apart from that, there doesn't seem to be a single original sentence in the article.
codingdave 8y ago
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.
- usefulcat 8y ago
  Maybe, but I would caution against assuming that either age or experience are antidotes to the phenomena described in the article. I've met some very experienced people (as in multiple decades of experience) who were still pretty insecure, and it definitely affected their work in exactly the ways described in the article. So to me it seems like genuine self confidence (or lack thereof) is a bigger factor.
- renox 8y ago
  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 8y ago
    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 8y ago
      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.
cmsj 8y ago
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.
- mkirklions 8y ago
  There will always be things you dont know. I've learned not to beat myself up about it.
  - tw1010 8y ago
    Yeah, if you still call yourself bad at something you've practiced daily for thirty years, most likely what needs to be corrected is not your skill set but your definition of competence.
    - ythn 8y ago
      Plus, programming is extremely broad. You could spend 10 years mastering embedded linux programming yet know little to nothing about data science programming, game programming, GPU/VFX/shader programming, HDL programming, etc. There's simply too much to learn.
    - OldSchoolJohnny 8y ago
      If you don't feel like you know less and less every year that you are doing something then you are not gaining any wisdom and will likely never be truly great at it.
- OldSchoolJohnny 8y ago
  Yes! This is a healthy attitude. Others say don't beat yourself up about it, I would say it's not about that, just not making assumptions that are useless.
- 8y ago
watwut 8y ago
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.
olavk 8y ago
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 8y ago
  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.
jm__87 8y ago
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.
forgottenpass 8y ago
>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?
azhu 8y ago
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.

112 points by rajasegarc 8y ago

deleted 8y ago

[deleted]

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 8y ago
Cognitive dissonance appears to be a very big problem with security - people not aggressively auditing their systems, rationalizing away concerns, etc.
- kazagistar 8y ago
  Agreed, but a lot of automatic security scanning is really heavy on false positives, which can be extra obnoxious for people.
- CJST_ 8y ago
  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 8y ago
    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 8y ago
      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.
ZainRiz 8y ago
Right. The author seems to talk about typos and simple bugs in the code, but every programmer makes those on a regular basis and no way anyone could deny such a bug when it's pointed out to them. This cognitive dissonance seems like it may be more applicable at a higher level, when talking about design flaws in the system. There the programmer can actually come up with excuses for their "issues". For example, if someone complains "but your design won't scale to 1 million customers" the programmer might reply "come one, we need to be fast" or "we won't need that kind of scale until years from now"

pdkl95 8y ago

> 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

bena 8y ago
I'd say it's way more the hypnosis reason. You stare at it and stare at it and get so used to it that you don't notice that you needed a > where you have a <.
howard941 8y ago
Reading through fn [1] was fun at first but now I feel very old and frail.
madeuptempacct 8y ago
What's a puffer train?
- pdkl95 8y ago
  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")
beat 8y ago
I think of that as a flaw of perception, not cognitive dissonance.

RegBarclay 8y ago

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 8y ago
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.

svat 8y ago

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

mannykannot 8y ago
I was about to say the same; the phrase "The programmer comes down the hall with his output listing and it is very thin..." certainly shows its age. The message, however, is just as relevant now as it was then.
huntie 8y ago
I just stumbled across Weinberg's book at the library yesterday and thought that it looked good. I'm glad to hear that it is.
pc86 8y ago
I think by definition if it's heavily plagiarized another source it's not a great article.
- d0lph 8y ago
  Not necessarily, humans are pretty derivative in general.
  - pc86 8y ago
    You can be derivative without plagiarizing someone else's work.
- svat 8y ago
  Depends on your definitions. If someone makes a copy of the Mona Lisa and claims it as their own, does it stop being a great painting? (Or if you don't think the Mona Lisa is a great painting, replace with whatever you think is.) In fact given what I can tell of the author(s) in this case, we should be grateful it's so heavily plagiarized; the less they plagiarized (and the more they inserted their own content), it seems the worse it would be. :-) ---------------------------------- BTW I took a look at the article again, and it contains solely of two paragraphs picked up verbatim from Wikipedia, followed by the remaining paragraphs each verbatim from book. The only changes I could detect were: 1. where the book mentions "Starting with the work of the social psychologist Festinger", the article has "Starting with the work of the social psychologist Leon Festinger" with a link to the Wikipedia article for him 2. the article introduces random bolding of various words 3. where the book says > There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple... the article says (turning the correct "hear" into "here") > There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple... Apart from that, there doesn't seem to be a single original sentence in the article.

codingdave 8y ago

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.

usefulcat 8y ago
Maybe, but I would caution against assuming that either age or experience are antidotes to the phenomena described in the article. I've met some very experienced people (as in multiple decades of experience) who were still pretty insecure, and it definitely affected their work in exactly the ways described in the article. So to me it seems like genuine self confidence (or lack thereof) is a bigger factor.
renox 8y ago
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 8y ago
  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 8y ago
    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.

cmsj 8y ago

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.

mkirklions 8y ago
There will always be things you dont know. I've learned not to beat myself up about it.
- tw1010 8y ago
  Yeah, if you still call yourself bad at something you've practiced daily for thirty years, most likely what needs to be corrected is not your skill set but your definition of competence.
  - ythn 8y ago
    Plus, programming is extremely broad. You could spend 10 years mastering embedded linux programming yet know little to nothing about data science programming, game programming, GPU/VFX/shader programming, HDL programming, etc. There's simply too much to learn.
  - OldSchoolJohnny 8y ago
    If you don't feel like you know less and less every year that you are doing something then you are not gaining any wisdom and will likely never be truly great at it.
OldSchoolJohnny 8y ago
Yes! This is a healthy attitude. Others say don't beat yourself up about it, I would say it's not about that, just not making assumptions that are useless.
8y ago

watwut 8y ago

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.

olavk 8y ago

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 8y ago
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.

jm__87 8y ago

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.

forgottenpass 8y ago

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

azhu 8y ago

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.