The Fundamental Attribution Error

Many people don't code. According to some academic studies, a significant number can't code; there is some essential conceptual block they have yet to hurdle. Of course this is controversial, and complex, and much-discussed.

I was just browsing the usual blogs on this cold morning and The Daily WTF had dug up the old fizzbuzz problem sometimes given as an interview question for new software developer hires. And an intriguing statement came out of one of the following links; that poor programmers didn't stumble on just the big, complicated problems, but on little problems as well. The problem seems to be with what some of us used to call thinking like the computer (the oft-repeated "it does what you said, not what you meant" problem).

And I can't help thinking that there may be links to the tech/non-tech dichotomy as well, plus could throw in the oft-observed (but less well studied) apparent statistical correlation between programmers and people on the autistic spectrum.




One of the articles I've looked at suggests that the problem may lie in modeling. That non-programmers attempt to map the behavior of a system to their existing internal models of the world, but programmers are willing to accept and work within the constraints of the machine's unique (and often counter-intuitive) internal model instead.

This seems to me to have some application to mathematics, and even a few soft sciences as well (ethnomusicology leaps to mind -- a difficult field to write academically in because you simultaneously have to work within a culture's unique mapping of the sound space, but document what they produce within the not-always-perfect mapping of the shared language of western tradition.)

The other thought that springs out is that rules-based behavior -- which I have noticed among non-technical people and commented on before -- makes sense within this mapping problem. In a rules-based system, you only have your internal model of the larger universe. Instead of abstracting and intuiting the internal state of a device or system, you establish a narrow, filtered connection to it.




Rules-based behavior -- what I also call magical thinking -- is a list of empirical solutions. I'm going to go back again to a simple system I observed at an old workplace. There were work lights in the wing that needed to be turned off during the play. Since the room could be approached from two directions, the original electricians had put in a two-way switch; you could switch on or off from either end of the room.

The tech approach is to model the system. Usually by direct experimentation (aka, flip the switches, figure out how it works). Or, more importantly, figure out an internal model; the truth table of that set of switches. Rules-based behavior wants to map a single action, (press this switch) to a desired result (turn the lights off). The user of a rules-based system needs to have made available a system that can be abstracted and limited to this simplicity.

The first attempt at documenting the rule was to label the switch. "Up" was equivalent to lights "On." The map matched the territory -- until the next time someone flipped the switch at the other end of the room. Now the map didn't match the territory. The solution? Re-label the switch, and tape over the other switch.

As a sound engineer or as a general stage technician one sees this sort of thing all the time. The usual wave-off is you are working with people who don't have the time or the interest to learn how the gadget they are abusing actually works. So we put up with equipment that breaks at inconvenient times (like in the middle of the show). But I've got a growing belief that this isn't a good picture -- that our model is incorrect.

Because we don't require the musicians on stage or the stage manager fumbling with a headset to understand the internal electronics of the gear. Sure, that may be the framework the technician used to arrive at their understanding. But it isn't necessary to get through a couple of years of technical eduction and basic electronics to construct a proper model of the underlying system.

What we may be dealing with, in short, is that same non-programmer problem; people who are unable to make the mental leap to modeling a system as it is, instead of trying to cram its behavior into their established system of beliefs.




I've often noticed and remarked on the difference in behavior between the tech and non-tech, the Morlock and Eloi of our overly-stretched and far-too-contrasty comparison here. Confronted with a new piece of technical equipment, the Morlock plays with it. The Eloi approaches tentatively, and only presses a control when they are assured that is the right button to press. When questioned, they may say they are "afraid of breaking something."

The Morlock scoffs that gear is harder to break than that. But that ignores two very important caveats behind their approach. The first is a robust general model formed from similar pieces of gear that informs them of the safe envelope for experimentation. They may flip all the switches on the surface of a new mixer safe in the knowledge that they probably can't break anything, but they know better than to fiddle with the small black switch cryptically labeled "120/240" on the back of the thing!

Plus, the Morlock knows that if they break it, they can probably fix it, and if it was that easy to break in the first place it probably needed to be replaced anyhow.




The Fundamental Attribution Error in psychology is, basically, attributing the behavior of others to internal factors ("He is such a rude person") whereas one's own behavior is seen as driven by external factors ("Sure I hung up on him, but he asked for it.")

Assignment is a fundamental error in programming (and in C-like typography, an error that everyone makes on a regular basis without requiring the influence of a poor mental model). The same interviewers who were startled at how many would-be programmers could not formulate an approach to a test problem in the fizzbuzz class were not particularly surprised by educators who found up to eighty percent of the students in first-year comp sci could not correctly answer;

a = 10;
b = 20;
a = b;
if (a < b) {
///does this line run?
}

(The more usual form of this mistake for most of us is "If (a = b){..." aka; typing "=" or assignment when we meant to type "==" or equivalence. Fortunately, the compiler tends to catch this kind of error!)

Apparently, though, and according to at least a small number of academic studies, the error of the students is not typographically based but stems from an incorrect or entirely missing internal model of how attribution works.

And as for fizzbuzz? I left it to the last, because it is also a truism that if you bring up fizzbuzz around any group of programmers discussion will instantly devolve into better (or, at least, more unique and esoteric) ways of programming it. There is something in the programmer that can not resist the urge to solve the problem -- well over the urge to discuss the context of solving the problem.

Yes, I immediately thought of my own. Using modulus, of course. But even if I had tackled it five years ago, before I realized the sheer power of "If (a % 5 == 0){", I could still have come up with a solution. It is a matter of matching the problem space with the space of the tools at hand. If nothing else, "If (a == 3 || a == 6 || a == 9..." would do the job, even if frighteningly brute-force. (Or for the true glutton, a "switch/case" stack 100 items long...)

And I don't know if this idea of being unable to adopt the internal model of the machine is a reasonable explanation for why some people don't seem to have the tech gene. I do know that trying to apply a (small) set of rules is not going to get you through a fizzbuzz problem.

Which may be the simplest way of looking at a thing that may be over-stated and over-complexed; that the Eloi problem is, in short, trying to simplify a complicated world into too small a set of rules.




Meanwhile, I'm spending Christmas morning sitting at home alone thinking about conceptual problems in computer programming. And if that isn't suggestive of a position somewhere on the high-functioning end of the spectrum, I don't know what is!

(Truth is -- I'm listening to Christmas-themed jazz tunes, the sun is coming through my window, I just got off the phone with Mom and I'm thinking about re-heating that pumpkin pie, and I'd say that life is pretty durn good.)