Cognitive Dissonance in Programming
hangaroundtheweb.com
hangaroundtheweb.com
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).
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.
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?
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.
I'm assuming the above is sarcasm?
> There are redundancies that should be > set up in the development process for > this reason.
Of course there should be tests, redundancies, fault-tolerant mechanisms and recovery systems _when_ errors/disasters occur. But these constructs are only functions of investments in time and money - and there is no absolute endpoint for tests which can signal that a program is completely error-free, only sufficiently error-free. And that word "sufficiently" is function of money and time. Developers and sponsors make explicit decisions about how much and what kind of testing is sufficient.
> Admitting the mistake gives you nothing > but low opinion of everyone involved. > (which is in itself sad)
If that has been your experience, would you mind sharing the anecdote(s)?
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.
One outcome of Crawford's analysis is that really skilled craftsmen (he would consider programming a craft) are excellent at admitting failure - it's the only path to success.
I do agree the author of the article doesn't seem to understand artists, and appears quite prejudiced against the artistic creative process. Creating art seriously is every bit as challenging as programming, mostly in the same ways.
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.
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"
I've learned not to beat myself up about it.
If they say 9/10 and they are not Bjarne Stroustrup, it's a good bet their actual ability is close to 1/10.
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?
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 <.
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")
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.
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.
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.
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.
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?
And so on.