The Psychology of Computer Programming

by Gerald M. Weinberg

The Hawthorne Effect ("the process of being observed often motivates people to better performance")

Managers who pay attention to people get good results.

much measurement seems to be designed to control individual programmers without interacting with them—that is, to force them to work according to some model that someone else thinks is the right way for them to program.

human interactions are never narrow, never straight, and hardly ever in the directions shown an organization charts.

informal mechanisms always exist and it is dangerous to change things without understanding them, lest you derange some smoothly operating system which you will not be able to replace at similar cost.

If asked, most programmers would probably say they preferred to work alone in a place where they wouldn't be disturbed by other people. The ideas expressed in the preceding paragraph are possibly the most formidable barrier to improved programming that we shall encounter.

Among the general personality traits is one which is measured along three "dimensions"—whether a person is "compliant," "aggressive," or "detached." The compliant type is characterized by the attitude of liking to "work with people and be helpful." The aggressive type wants to "earn money and prestige," and the detached type wants to "be left to myself to be creative."

every person contains a mixture of these attitudes, but most people lean more heavily in one direction than the others.

the majority of people in programming today lean in the "d...

Starting with the work of the social psychologist Festinger, a number of interesting experiments have been performed to establish the reality of a psychological phenomenon called "cognitive dissonance."

To resolve a dissonance, one factor or another contributing to it must be made to yield. Which factor depends on the situation, but, generally speaking, it will not be the person's self-image. That manages to be preserved through the most miraculous arguments.

This is an example of anticipating the possibility of dissonance and avoiding information that might create

A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program.

the human eye has an almost infinite capacity for not seeing what it does not want to see.

Programmers, if left to their own devices, will ignore the most glaring errors in their output—errors that anyone else can see in an instant.

the problem of the ego must be overcome by a restructuring of the social environment

John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work.

His very ability to realize his human limitations put him head and shoulders above the average programmer today.

Average people can be trained to accept their humanity—their inability to function like a machine—and to value it and work with others so as to keep it under the kind of control needed if programming is to be successful.

If it is true that programmers have bad coding days—and this seems supported from a number of sources—then a piece of code written on one of these days is going to have an extra long debugging cycle.

Fixation occurs whenever a situation creates an environment favorable for maintaining that situation.

One typical computing example of social fixation is the adoption of one programming language by an installation.

In the same way that an installation fixates on a programming language, it can establish a general social environment which either encourages or discourages egoless programming.

Managers tend to select themselves from the "aggressive" component of society and have difficulty appreciating the fact that other people do not completely share their goals of money and prestige.

If any one thing proves that psychological research has been ignored by working managers, it's the continuing use of half-partitions to divide workspaces into cubicles.

DeMarco and Lister's Peopleware would set that issue to rest once and for all. That is, I might have thought so if I hadn't learned about the managerial psychology that puts social status above productivity.

"I believe the issue is even deeper than social status. I don't know how Peopleware became a best seller. I never run into any managers who have read it. Beyond that, I hardly run into any managers who read about their industry, management theory, or psychology, period. I used to believe that they were overloaded with information regarding the specifics of their job, but frankly, managers still aren't trained, or do not educate themselves, to do their jobs. As for social status, IT managers have been status deprived in their organizations since they were developers, so status is even more important to them than their peers in other lines of business. I am amazed at some of the corner office kingdoms that CIO's create for themselves."

I would use the much more descriptive Myers-Briggs Personality Inventory (MBTI),

I've found the MBTI most helpful in understanding certain tendencies in programmer/manager behavior,

If your reasons for not wanting your code reviewed are not based on logic, you'll never be convinced to change your ways by logical arguments. And, if you're not using logic about your professional life, your professionalism is severely limited.

But I'm not discouraged. I see the emergence of Agile (and other) programming teams as the great hope for the future.

Schedule is similarly limiting—we need only cite the apocryphal experiment which tried to make a baby in one month by putting nine women to work on the job as a team.

almost any program can be produced with less programming talent—if we are willing to allow a stretching of the schedule, and if we have not dropped below the minimum competence.

three programmers organized into a team can do only twice the work of a single programmer of the same ability—because

is doubtful whether nine programmers can do anything useful in less than about two months,

for the best programming at the least cost, give the best possible programmers you can find sufficient time so you need the smallest number of them.

the worst way to do a programming project is to hire a horde of trainees and put them to work under pressure and without supervision—although this is the most common practice today.

These anthropomorphisms do not have to represent rational thinking in order to be important factors in determining team satisfaction with work assignments.

To achieve true consensus on group goals, there is no better method than having the group set the goals itself.

even more difficult situations arise when a group has reasonably clear goals, but has more than one at a time.

The persistence of this kind of argument among team members can reliably be taken as a sign of some deeper conflict—perhaps for "leadership" of the team—and should not be ignored simply on account of its triviality.

Leadership, in the sense that social scientists use it, means the ability to influence people.

When non-programming leaders are brought in to be in charge of programming teams, trouble usually brews unless the appointed leader explicitly and implicitly recognizes his incapacity on technical matters.

Even assuming that the team could be made to give in, nobody who has ever seen the performance of a programming group which has so knuckled under would desire this result.

The important factor in democratic group functioning is not that every member exerts equal leadership, but that the determinants of leadership are based on the inner realities of team life, not imposed from outside.

In a democratically organized group—given, of course, sufficient talent and intelligence to draw upon—the right man can be chosen for each time.

What the team leader must learn is that • Managers—no matter how hard they press for promises—really want results. • Results will be far more easily obtained if they are obtained in the pursuit of goals set with full team participation.

One of the paradoxes of leadership is simply this: only the leader who is ready to step down has a real chance of success.

Paradoxically as it may seem to some, the democratically organized team may present to outsiders a rather cold and unfriendly facade, whereas the members of an authoritarian team may be most warm and friendly toward a newcomer.

in a democratic team, an antisocial member cuts lines of communications and is a constant impediment to consensus in team meetings.