The Psychology of Computer Programming

by Gerald M. Weinberg

"And how long does your program take?" he asked—emphasizing the possessive. "That varies with the input," was the reply, "but on the average, about ten seconds per entry." "Aha," was the triumphant reply. "But my program takes only one second per entry."

"But your program doesn't work. If the program doesn't have to work, I can write one that takes one millisecond per entry—and that's faster than we can input an entry."

Lacking any objective measure, we often judge how difficult a program is by how hard a programmer works on it. Using this sort of measure, we can easily fall into believing that the worst programmers are the best—because they work so hard at it.

People who spend much time debugging other people's programs soon learn not to listen to explanations before tackling the problem. Such explanations tend to put the listener on the same false track of assumptions that prevented the speaker from finding the bug for himself.

Yes, intelligence is a factor in programming success—people with an IQ less than 50 are probably not going to create operating systems (although they might design new languages—the Devil made me say that).

"... intelligence has less to do with the matter than personality, work habits, and training. These things, unlike intelligence, can be changed by experience later in life, which turns the problem from one of selecting programmers to creating them."

My own doctoral thesis showed quite clearly that problem solving style was unique to the individual. Thus, anything that forces a programmer to think in another person's style reduces that programmer's ability to solve problems. The greatest challenge, then, is not creative thinking, but creative communicating: representing our thoughts in a way that other persons—each with a unique style—can understand.

When faced with a problem arising out of some unfamiliar situation, there are two general errors we can make—either we think the problem is harder than it really is or we think it is easier than it really is.

we are looking in the wrong place because we assume —as is quite natural to do—that only what we see at the moment in front of our nose is what affects the value of I. In whichever programming language we use, when debugging we must learn in what ways nonlocal effects can manifest themselves.

Overconfidence by the programmer could be attacked by a system that introduced random errors into the program under test. The location and nature of these errors would be recorded inside the system but concealed from the programmer. The rate at which he found and removed these known errors could be used to estimate the rate at which he is removing unknown errors.

In a way, then, if the programmer has invested very little waiting time in a run, he may tend to value that run less—an observation which seems to hold for certain terminal systems as well.

We can also predict that most of today's programmers won't enjoy changing the definition of their fundamental work—we know, because we didn't enjoy it. Hey, there was something really satisfying about carrying your program deck in both hands, securely fastened with two rubber bands; carefully removing those rubber bands; placing the deck in the card reader; pressing the start button; watching those cards stack up in the tray; pressing end-of-file to run out the last of them; removing them; riffling them to drop out any chad; squaring them up on the special platform; replacing the rubber bands; and carrying that solid deck back to your desk! That was true integration, and some of us miss the feeling of control.

I now realize, to expect that bad systems cannot be built by people with good hearts. Otherwise, why would I encounter so many bad systems when almost all of the people I meet are wonderful?