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"
Re:Cognitive Dissonance in Programming
by mannykannot on Thursday August 02, 2018 @09:33AM
(#17671238)
Cognitive dissonance appears to be a very big problem with security - people not aggressively auditing their systems, rationalizing away concerns, etc.
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).
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.
Re:Cognitive Dissonance in Programming
by mannykannot on Thursday August 02, 2018 @04:15PM
(#17675078)
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.
Re:Cognitive Dissonance in Programming
by kazagistar on Thursday August 02, 2018 @11:10AM
(#17672029)
Agreed, but a lot of automatic security scanning is really heavy on false positives, which can be extra obnoxious for people.
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.