Science and the Compulsive Programmer

from Computer Power and Human Reason [1976]

by Joseph Weizenbaum

The computer programmer, however, is a creator of universes for which he alone is the lawgiver. So, of course, is the designer of any game. But universes of virtually unlimited complexity can be created in the form of computer programs. Moreover, and this is a crucial point, systems so formulated and elaborated act out their programmed scripts. They compliantly obey their laws and vividly exhibit their obedient behavior. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or a field of battle and to command such unswervingly dutiful actors or troops.

One would have to be astonished if Lord Acton’s observation that power corrupts were not to apply in an environment in which omnipotence is so easily achievable. It does apply. And the corruption evoked by the computer programmer’s omnipotence manifests itself in a form that is instructive in a domain far larger than the immediate environment of the computer. To understand it, we will have to take a look at a mental disorder that, while actually very old, appears to have been transformed by the computer into a new genus: the compulsion to program.

Wherever computer centers have become established, that is to say, in countless places in the United States, as well as in virtually all other industrial regions of the world, bright, young men of disheveled appearance, often with sunken glowing eyes, can be seen sitting at computer consoles, their arms tensed and waiting to fire their fingers, already poised to strike, at the buttons and keys on which their attention seems to be as riveted as a gambler’s on the rolling dice. When not so transfixed, they often sit at tables strewn with computer printouts over which they pore like possessed students of a cabalistic text. They work until they nearly drop, twenty, thirty hours at a time. Their food, if they arrange it, is brought to them: coffee, Cokes, sandwiches. If possible, they sleep on cots near the computer. But only for a few hours—then back to the console or the printouts. Their rumpled clothes, their unwashed and unshaven faces, and their uncombed hair all testify that they are oblivious to their bodies and to the world in which they move. They exist, at least when so engaged, only through and for the computers. These are computer bums, compulsive programmers. They are an international phenomenon.

How may the compulsive programmer be distinguished from a merely dedicated, hard-working programmer? First, by a fact that the ordinary professional programmer addresses himself to the problem to be solved, whereas the compulsive programmer sees the problem mainly as an opportunity to interact with the computer. The ordinary computer programmer will usually discuss both his substantive and his technical programming problem with others. He will generally do lengthy preparatory work, such as writing and flow diagramming, before beginning work with the computer itself. His sessions with the computer may be comparatively short. He may even let others do the actual console work. He develops his program slowly and systematically. When something doesn’t work, he may spend considerable time away from the computer, framing careful hypotheses to account for the malfunction and designing crucial experiments to test them. Again, he may leave the actual running of the computer to others. He is able, while waiting for results from the computer, to attend to other aspects of his work, such as documenting what he has already done. When he has finally composed the program he set out to produce, he is able to complete a sensible description of it and to turn his attention to other things. The professional regards programming as a means toward an end, not as an end in itself. His satisfaction comes from having solved a substantive problem, not from having bent a computer to his will.

The compulsive programmer is usually a superb technician, moreover, one who knows every detail of the computer he works on, its peripheral equipment, the computer’s operating system, etc. He is often tolerated around computer centers because of his knowledge of the system and because he can write small subsystem programs quickly, that is, in one or two sessions of, say, twenty hours each. After a time, the center may in fact be using a number of his programs. But because the compulsive programmer can hardly be motivated to do anything but program, he will almost never document his programs once he stops working on them. A center may therefore come to depend on him to teach the use of, and to maintain, the programs that he wrote and whose structure only he, if anyone, understands. His position is rather like that of a bank employee who doesn’t do much for the bank, but who is kept on because only he knows the combination to the safe. His main interest is, in any case, not in small programs, but in very large, very ambitions systems of programs. Usually the systems he undertakes to build, and on which he works feverishly for perhaps a month or two or three, have very grandiose but extremely imprecisely stated goals. Some examples of these ambitions are: new computer languages to facilitate man-machine communication; a general system that can be taught to play any board game; a system to make it easier for computer experts to write super-systems (this last is a favorite). It is characteristic of many such projects that the programmer can long continue in the conviction that they demand knowledge about nothing but computers, programming, etc. And that knowledge he, of course, commands in abundance. Indeed, the point at which such work is often abandoned is precisely when it ceases to be purely incestuous, i.e., when programming would have to be interrupted in order that knowledge from outside the computer may be acquired.

Unlike the professional, the compulsive programmer cannot attend to other tasks, not even to tasks closely related to his program, during periods when he is not actually operating the computer. He can barely tolerate being away from the machine. But when he is nevertheless forced by circumstances to be separated from it, at least he has his computer printouts with him. He studies them, he talks about them to anyone who will listen—though, of course, no one else can understand them. Indeed, while in the grip of his compulsion, he can talk of nothing but his program. But the only time he is, so to say, happy is when he is at the computer console. Then he will not converse with anyone but the computer. We will soon see what they converse about.

The compulsive programmer spends all the time he can working on one of his big projects. “Working” is not the word he uses; he calls what he does “hacking.” To hack is, according to the dictionary, “to cut irregularly, without skill or definite purpose; to mangle by or as if by repeated strokes of a cutting instrument.” I have already said that the compulsive programmer, or hacker as he calls himself, is usually a superb technician. It seems therefore that he is not “without skill” as the definition would have it. But the definition fits in the deeper sense that the hacker is “without definite purpose”: he cannot set before himself a clearly defined long-term goal and a plan for achieving it, for he has only technique, not knowledge. He has nothing he can analyze or synthesize; in short, he has nothing to form theories about. His skill is therefore aimless, even disembodied. It is simply not connected with anything other than the instrument on which it may be exercised. His skill is like that of a monastic copyist who, though illiterate, is a first-rate calligrapher. His grandiose projects must therefore necessarily have the quality of illusions, indeed, of illusions of grandeur. He will construct the one grand system in which all other experts will soon write their systems.

● ● ●

Programming systems can, of course, be built without plan and without knowledge, let alone understanding, of the deep structural issues involved, just as houses, cities, systems of dams, and national economic policies can be similarly hacked together. As a system so constructed begins to get large, however, it also becomes increasingly unstable. When one of its subsystems fails in an unanticipated way, it may be patched until the manifest trouble disappears. But since there is no general theory of the whole system, the system itself can be only a more or less chaotic aggregate of subsystems whose influence on one another’s behavior is discoverable only piecemeal and by experiment. The hacker spends part of his time at the console piling new subsystems onto the structure he has already built—he calls them “new features”—and the rest of his time in attempts to account for the way in which substructures already in place misbehave. That is what he and the computer converse about.

The psychological situation the compulsive programmer finds himself in while so engaged is strongly determined by two apparently opposing facts: first, he knows that he can make the computer do anything he wants it to do; and second, the computer constantly displays undeniable evidence of his failures to him. It reproaches him. There is no escaping this bind. The engineer can resign himself to the truth that there are some things he doesn’t know. But the programmer moves in a world entirely of his own making. The computer challenges his power, not his knowledge.

Indeed, the compulsive programmer’s excitement rises to its highest, most feverish pitch when he is on the trail of a most recalcitrant error, when everything ought to work but the computer nevertheless reproaches him by misbehaving in a number of mysterious, apparently unrelated ways. It is then that the system the programmer has himself created gives every evidence of having taken on a life of its own and, certainly, of having slipped from his control. This too is the point at which the idea that the computer can be “made to do anything” becomes most relevant and most soundly based in reality. For, under such circumstances, the misbehaving artifact is, in fact, the programmer’s own creation. Its very misbehavior can, as we have already said, be the consequence only of what the programmer himself has done. And what he has done he can presumably come to understand, to undo, and to redo to better serve his purpose. Accordingly his mood and his activity become frenzied when he believes he has finally discovered the source of the trouble. Should his time at the console be nearly up at that moment, he will take enormous risks with his program, making substantial changes, one after another, in minutes or even seconds without so much as recording what he is doing, always pleading for just another minute. He can, under such circumstances, rapidly and virtually irretrievably destroy weeks and weeks of his own work. Should he, however, find a deeply embedded error, one that actually does account for much of the program’s misbehavior, his joy is unbounded. It is a thrill to see a hitherto moribund program suddenly come back to life; there is no other way to say it. When some deep error has been found and repaired, any different portions of the program, which until then had given nothing but incomprehensible outputs, suddenly behave smoothly and deliver precisely the intended results. There is reason for the diagnostician to be pleased and, if the error was really deep inside the system, even proud.

But the compulsive programmer’s pride and elation are very brief. His success consists of his having shown the computer who its master is. And having demonstrated that he can make it to do this much, he immediately sets out to make it do even more. Thus the entire cycle begins again. He begins to “improve” his system, say, by making it run faster, or by adding “new features” to it, or by improving the ease with which data can be entered into it and gotten out of it. The act of modifying the then-existing program invariably causes some of its substructures to collapse; they constitute, after all, an amorphous collection of processes whose interactions with one another are virtually fortuitous. His apparently devoted efforts to improve and promote his own creation are really an assault on it, an assault whose only consequence can be to renew his struggle with the computer. Should he be prevented from so sabotaging his own work, say, by administrative decision, he will become visibly depressed, begin to sulk, display no interest in anything around him, etc. Only a new opportunity to compute can restore his spirit.