One of the early chapters of The Psychology of Computer Programming, Silver Anniversary Edition (Gerald M. Weinberg, $44.95, Dorset House Publishing, 1998; originally published in 1971) describes a programmer using an end-of-file punch card to work around a limitation of the language he’s using. That’s right, there’s no need to adjust your monitor. I did indeed say “punch card.” So what can a book old enough to use such an antiquated term have to say that can possibly be relevant for today’s developer? The answer is plenty. You see, although the technology has dramatically changed, the people programming the technology have not.

Why am I calling this book a classic? The fact that it’s still in print at 30 years of age carries some weight. More importantly, I believe the topics discussed in this book will seem so relevant you’ll forget that what you’re reading was written 30 years ago. That is, until the author includes some FORTRAN source or mentions a punch card.

Four-step program for programmers
Weinberg writes with an engaging style and uses humorous anecdotes to illustrate many of his points. As a result, The Psychology of Computer Programming doesn’t read like the textbook it was intended to be, and it’s easy to forget that the topics are backed by Weinberg’s research. The book is divided into four parts, each covering a different view of computer programming. These parts are subdivided into chapters, and each chapter includes discussion questions and is annotated by the author with comments written specifically for the Silver Anniversary Edition.

Part 1, “Programming as Human Performance,” examines the human element of computer programming and discusses how and why different programmers perform the same task differently and with varying levels of competence. Weinberg compares the act of programming to a mystical art and then questions this comparison by asking if programmers are made or born—or are some combination of the two. The author also describes some of his research methodologies and answers the question of how to study this ephemeral thing we call programming.

In Part 2, “Programming as Social Activity,” Weinberg examines the social interactions that occur among programming teams and between them and their ancillary groups like QA. The section also explores some different management styles. The author relays several humorous stories of new programming managers who failed miserably either because their style was incompatible with, or they were ignorant of, their programmers’ strengths and weaknesses.

My favorite story involves a new and very authoritarian manager who had, upon making the appalling discovery that some of his programmers were dragging into the office at 10 A.M., instituted an attendance policy strictly enforcing office hours. He failed to consider that those programmers he saw coming in late had been working until 2 A.M. the previous night as part of a staggered shift plan to optimally use limited computer time. The result was predictable: Programmers began to line up at the time clock to go home and the mainframe went unused at night while programmers sat idle during the day waiting for machine time. While showing us that programmers did indeed work incredibly long hours back then, this example also illustrates how authoritarian management styles usually fail when applied to the management of software development and programmers.

Part 3, “Programming as an Individual Activity,” discusses the stages of the software development process and the effects that different programmer traits, such as problem-solving ability, training, and experience, have on the process. Included in this section is Weinberg’s oft-quoted definition of a professional programmer: “Almost invariably, the sole intended user of an amateur’s program is the amateur himself, whereas the professional is writing programs which other people will use.”

The final section of the book, “Programming Tools,” includes, obviously enough, discussions of programming languages and which factors make them more (or less) efficient to use and learn. Of course, most of this section will have purely historical importance to most of us; exciting innovations from 30 years ago will seem obvious to readers today. However, I still found chapter 12, and its tips on constructing new programming languages, to be particularly interesting.

The sales pitch: Why you should own this book
From the state of mind of individual programmers in their cubicles to the social dynamic of the entire project’s cube farm, the psychological aspects of software development are what this book is all about. Even if you aren’t interested in all that, the rampant anachronisms, like punch cards, and the author’s many predictions for the future of the industry make for an interesting read. (If you are keeping score, he totally missed the boat on e-mail.)

The theories expressed in the book constitute the underpinnings of most software management theory, a topic painfully absent from the “Learn ‘foo’ in 24 easy lessons” formula that currently dominates the technical book industry. As such, The Psychology of Computer Programming deserves study by anyone who has to work with programmers, and it should be on the shelves of developers and managers alike.