BookReview: Psychology of Computer Programming
by Gerald M. Weinberg, Van Nostrand Reinhold Company, 1971, 0-442-29264-3

Excellent discussion of the problems in computer programming along with reasonable approaches towards solving them. His annotated bibliographies at the end of each chapter are good. In fact the whole book is well organized.

[p3] "The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when he contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries to comprehend a little of this mystery every day. Never lose a holy curiosity." -- Albert Einstein [From Death_of_a_Genius, by William Miller, LIFE Magazine, May 2, 1955]

[p53] Well, what is wrong with "owning" programs? Artists "own" patings; authors "own" books; architects "own" buildings. Don't these atrributions lead to admiration and emulation of good workers by lesser ones? Isn't it useful to have an author's name on a book so we have a better idea of what to expect when we read it? And wouldn't the same apply to programs? Perhaps it would--if people read programs, but we know that they do not. [Rob: 20 years later and still true.] Thus, the admiration of individual programmers cannot lead to an emulaton of their wokr, but only to an affectation of their mannerisms. This is the same phenomenon we see in "art colonies," where every knows how to look like an artist, but few, if any, know how to paint like one.

The real difficulty with "property-oriented" programming arises from another source. When we think a painting or a novel or a building is inferior, that is a matter of taste. When we think a program is inferior--in spite of the difficulties we know lurk behind the question of "good programming"--that is a matter at least potentially susceptible to objective proof or disproof. At the very least, we can put the program on the machine and see what comes out. An artist can dismiss the opinions of a critic if they do not please him, but can a programmer dismiss the judgment of the computer?

On the surface, it would seem that the judgment of the computer is [p54] indisputable, and if this were truly so, the attachment of a programmer to his programs would have serious consequences for his self-image. When the computer revealed a bug in his program, the programmer would have to reason something like this:

"This program is defective. This program is a part of me, an

extension of myself, even carrying my name. I am defective." But the very harshness of this self-judgment means that it is seldom carried out.

[Discussion of cognitive dissonance.]

[p55] Now, what cognitive dissonance has to do with our programming conflict should be vividly clear. 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. On the contrary, he is going to be trying to prove that the program is correct--even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with the symptoms of this dissonance resolution--in others, of course. The programmer comes down the hall with his output listing and it is very thin. If he is unable to conceal the failure of his run, he makes some remark such as

"Those keypunch operators did it again."


There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple

"I goofed again."

[p56] EGOLESS PROGRAMMING [...] The problem of ego must be overcome by a restructuring of the social environment and, through this means, a restructuring of the value system of the programmers in that environment.


One typical computing example of social fxation is the adoption of one programming language by an installation. Once the language has been adopted, a new language has more difficulty making and entry, because with most ofthe people using the old language, advantages accrue to following the beaten path. If one needs advice, it is more easily found. If one needs subroutines, they are more likely to exist. [...]

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. When a new programmer enters the mileu, his attitudes may be shaped by the reactions of the others already there. If he goes to somebody for advice and he is ridiculed for the stupidity of his errors, he is less likely to seek assistance the next time. [...]

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. They are especially at a loss to understand the smooth functioning of a programming rgoup based on mutual respect for individual talent and cooperation in the common cause.

Another point about fixation is Weinberg's persistent use of the masculine singular to refer to programmers, thus perpetuating the male domination of the industry. This becomes apparent later.

[p76] [The] main lesson is the difference between [false} consensus--whiche stifles the healthy disagreement essential to unbiased appraisal of programming work--and consensuson the goals of the team--which smooths the way for productive functioning.

To achieve true consensus on group goals, there is no better method than having the group set the goals itself. For one thing, participating in setting the goals ensures that the goals will be more clearly understood. For another, it gives each group member a chance to commit himself publicly to the group's goal, and this type of public commitment--purhaps because of cognitive dissonance--has been shown to enhance goal acceptance. [...] The greatest danger is the manager who has come up through the programming ranks and wants to define every bit and byte before the team even sees the problem. [...] When a team does work from this sort of "bit-picking" specification, other troubles arise simply because what the group is trying to accomplish is not clear. Precision and clarity are not the same. To be clear--and goal clarity is one of the most critical factors in goal acceptance--the taks outlined must be placed in a framework of the meaning of what is being done. The programmer wants to know why, not just what.

[p77] Problems of unclear goals become more acute when the programming team is working not to produce a specific system, but to provide some service or support function to other groups. [...] [A] support group must be constantly reminded of their contribution, lest they drift into doing things more concrete but less productive. [...] There is no remedy for such drifting away from group goals unless there is competence in the installation to evaluate whether or not the group is working according to their mandate. Perhaps even more difficult situations arise when a group has reasonably clear goals, but has more than one at a time. [...] [When] a team has two distinct programs to produce [...] the relative importance of the two projects must be made clear initially and must be reclarified regularly, lest the quite natural drift in favor of one or the other should occur.

[p80] To be sure, there are instances of underpayment in this generally high-salaried profession, there are dull jobs, and there are bad companies. But these are exceptions, whereas bad supervision and leadership is more common than we would like to imagine. Thus, the attitude of a programmer toward his "superiors" is more likely to be the cause of dissatisfaction--with consequent loss of productivity--than perhaps all the other three put together.

[p82] The Swiss, for example, elect a general to head their armies when war threatens. When there is no war threat, there is no general--but there are other leaders chosen according to what needs there are for leadership. The Swiss, unlike certain other countries, are not burdened by general trying to govern the country in peacetime.

[p85] [Harold M--Almost all of Weinberg's programmers are male--says] "If I'm the only one who understands, then I'm the only one who really understands and you'll have to do it my way. If not, then you won't have any trouble replacing me. It's your problem, not mine, so if you'll excuse me, I'll get back to work."

Did Harold lose his job? He didn't, in this case; but that wasn't really important, for he knew he could get another at least as good. If it had been important, he wouldn't have been able to do what he did. One of the paradoxes of leadership is simply this: only the leader who is ready to step down has a real chance of success.


[...] [The] life story of a typical programming team would make the subject of a fairly interesting--if slightly unbelieveable--novel.

[Rob: Did Tracy Kidder get his idea for the Soul of a New Machine from this book?] [...]

In certain types of groups, and often in programming teams, the group tends to choos two complementary leaders--a task-specialist who sets, allocates, and coordinates the work; and a maintenance-specialist, who irons out conflicts among group members or between individual goals and group goals. The designated leader, because of his role in carrying external goals into the group, is most often in the task-specialist position, although, as we know, he may be replaced by the group if he does not display the necessary competence. The maintenance-specialist--who will more often be the best-liked person in the group--can come from anywhere. He may not be a particularly good programmer in his own right, though he may well be. Very often, he will be a she. [Rob: Can you say sexist?]

In one cross-cultural study of nuclear families--father, mother, and their children--this same division into task and maintenance activities was usually found at least in the cultural ideal. In most cultures, including ours, but not in all, the ideal father was the task-specialist and the ideal mother the maintenance-specialist. Perhaps this role for a female programmer is quite a natural one in our culture. In any cause, it seems quite frequent that when there is a woman on a programming team, she [p86] assumes the role of "team-mother," although no studies have been made to verify sex as a significant factor in choosing maintenance-specialist. There have been at least several teams where one of the women was openly referred to as the "team-mother" or "den-mother," [Rob: "The Mother of All Programmers" as Saddam Hussein would say...] and there is the persistent joke in computing circles which defines "software" as "a girl programmer." [Rob: This was 1971!] [...] Whether or not this maile-female division of leadership is ultimately shown to have social-psychological validity, there is sufficient anecdotal evidence to make it a worthwhile experimental [Rob: Experimental?!?] practice to place at least one woman programmer on each team, though probably not in the role of designated leader. Of course, there is no reason why a woman, as in many families, [Rob: Actually, the vast majority of ghetto families have a women head and half have no male at all.]

cannot take the task-specialist role; but managers should be wary of promoting a woman to be designated leader simply because she seems to be second-in-command in a team. In fact, there is no need to limit this caveat to women[.] [Rob: Then why mention them separately?]

[p90] Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden progarmming team. First of all, it has been observed that in a crisis, members of a group more readly accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team--which is possibly in a continual crisis [!]--leadership patters may be in constant flux. [!!] Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.

[p94] Kohn, Hans, Nationalism and Liberty: The Swiss Example, London, George Allen and Unwin Ltd., 1956.

A little introduction for those who have become disillusioned with the possibilities of democracy, those who have forgetten them, or those who never knew them in the first place. After reading the book, another step in re-education is to go there.

[p99] A project is not a house of cards which collapses when a single "key" person is removed. At [p100] least, it should not be; but often, when management thinks it is, the prophecy becomes self-fulfilling. If_a_programmer_is_indispensable,get rid of himas quickly_as_possible.

[p105] Recognizing that even a single ally can provide a safety valve to release the social pressure to produce conforming opinions, some programming projects have established a "devil's advocate" system for their management meetings. In a typical situation, a technical staff assistent to the project manager assumes this role. In every meeting, it is his duty to raise all possible negative points to opinions whicha all the others seems to share. By thus expressing disagreement with the group, he provides an anchor point for anyone whose lurking doubts were being restrained by the difficult of being one against many. [p106] [...] Some projects attempt to avoid this personalizing of the devil's advocate role by rotating the position among the various leaders from one meeting or one report to the next.

[p108] [We] do know through our experiences with egoless programming that there is no particular reason why your friend cannot also be your sternest critic.

[...] In the army--old-fashioned style--every footsoldier was considered interchangeable with every other. The hierarchical organization, then, was conceived as the structure that could give the fastest and most direct coordination between these interchangeable parts. [...] There is no need for [p109] the speed of communication which is necessary under field conditions, nor are the things to be communicated so simple that they can be barked over a two-way randio with shells bursting in the background. What is needed in a programming project is slow, careful communication among teams of people doing very different, highly specialized tasks.

[p111] The difference between these two titles is that secretaries are always female, and administrative assistants are may be of either gender. [!] The prettiest secretary may be a status symbol[!]

This association of women with the menial tasks of an office and of good looks with poor brains is the source of one of the more serious social problems in large projects--the sex problem. One of the women in our class undertook to study the attitudes about women programmers of men in her project. The picture that emerged from this survey was of men (especially older ones [Rob: Like the author?] ) who plastered over their insecurities by belittling the women who were involved in professional work.

[p112] Most men, of course, will dismiss these observations as not being serious. "Of course men talk about women in those ways, but a little friendly joking never hurt anybody." [p48 She was an attractive young thing...Besides, she enjoyed talking to all these bright young {he left out attractive} programmers--and they, let us admit, enjoyed talking to her.] Even the women who are not professionally involved tend to support the system by taking every opportunity to express disbelief that other women could "do such complicated things"--meaning, "compete with men." But to the women involved, the matter is deadly serious--though they are not about to let any curious male know about it. In many projects, women are systematically excluded from management positions, or management positions above the first level. [Wake up and smell the coffee, Gerry! Managers are supposed to be "wary of promoting a woman"!] [...] [Any] manager who won't promote a woman can point to a case where a woman was promoted and then left to have a baby or to follow her husband to his new job. And, of course, if a woman doesn't have babies or follow her husband, he says, "What kind of woman is she?"

Each prejudice has its price. [...] Although prejudices against other groups can also be serious matters, the prejudice against women is so common in programming that it merits special attention. Possibly the greatest single action to relieve the shortage of programming and programming management talent would be to start treating women as true equals--if indeed they are only that.

[p136] [A] project that can divide the effort not into programs but into types of work might realize gains in productivity of this magnitude [thirty-to-one]. Notice this is precisely what happens when egoless programming is practiced; and as long as programmers "own" programmers rather than, possibly, "owning" programming stages, we are not going to realize these potential gains.

[p196] All too often the program that "works" is mistaken for the program that is finished, frequently because of management pressure to "produce." But the programmer who wants to learn must resist such pressures and take the time to review his success. It might be good practice for management to give the programmer a day off when his project is "finished," not so much as a reward but as a chance to get a little perspective.

[p209] Later, when we discuss language design and program testing, we shall see that the correlation between the esthetic and the pragmatic value of a program is not accidental--the more pleasing to the eye and mind, the more likely to be correct. Or, put more poetically, "Beauty is truth, truth beauty."

[p211] Generally speaking, we only know how bad our present programming language is when we finally overcome the psychological barriers and learn a new one. Our standards, in other words, are shifting ones--a fact that has to be taken into full consideration in programming language design.

[p262] The value of documentation is only to be realized if the documentation is well done. If it is poorly done, it will be worse than no documentation at all.

[p279] [Rob: Strange segue] We stand at the brink of a new age, an age made possible by the revolution htat is embodied in the computer. Standing on the bring, we could totter either way--to a golden age of liberty or a dark age of tyranny, either of which would surpass anything the world has ever known. Perhaps no individual's efferts will make any difference in the result, but we must never cease trying, for then the result is sure to be tyranny. This book is my effort against tyranny, the enslavement of men by other men and by their own ignorance. Would that it not be adopted by the forces of tyranny themselves, as no doubt it will be. Lacking that hope, I can only hope that its use to the other forces will, in the balance, be greater.

Via Rob 1992