‘The Psychology of Computer Programming’ Category Archives


How can we study programming?

by Tony in The Psychology of Computer Programming

When you don’t know very much about a subject, you don’t know in advance what to measure. So your early experiments are not what they might seem to be—they are not to measure things, but to determine what can be measured and what can be worth measuring. The difference here is well exemplified by the difference between the methodologists of anthropology and sociology. The sociologist is working in his own culture, about which he assumes that he is sufficiently knowledgeable to construct, say, a questionnaire as a measuring instrument. But the anthropologist cannot use a questionnaire because he does not know what questions will be meaningful in another culture. Roughly, then, we might say that the sociologist is looking for answers, and the anthropologist is looking for questions.

The social science that provides us with the most useful overall model for computer programming is anthropology. With a little artistic license and stretching of the imagination, we could imagine computer programmers as having a culture—a shared set of beliefs and activities which shape their day-to-day activities. In our study of programming, we shall first examine the “social structure” of that culture— the way programmers relate to one another and to other people who are not programmers. We shall find some surprising possibilities for improvement in this area over present practices, more even than in the second area of study—programming as an individual activity.

— Gerald Weinberg, The Psychology of Computer Programming, Chapter 3


What makes a good program?

by Tony in The Psychology of Computer Programming

No doubt there are programs that are used once and then thrown away. No doubt there are even more programs that should be thrown away before ever being used. Nonetheless, the great majority of programs that are written, especially by professional programmers, remain in existence for a definite life span. And during that span, most of them become modified.

Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why, then, when we are forced to modify programs do we find it such a Herculean task that we often decide to throw them away and start over? Reading programs gives us some insight, for we rarely find a program that contains any evidence of having been written with an eye to subsequent modification. But this is only a symptom, not a disease. Why, we should ask, do programmers, who know full well that programs will inevitably be modified, write programs with no thought to such modifications? Why, indeed, do their programs sometimes look as if they had been devilishly contrived to resist modification—protected like the Pharaoh’s tomb against all intruders?

— — Gerald Weinberg, The Psychology of Computer Programming, Chapter 2

Answers on a postcard, please!


Reading Programs

by Tony in * commentary, The Psychology of Computer Programming

A young novelist of our time was recently asked who were this favorite authors. He responded simply that he never read novels, as his ideas were so new and superior to anyone else’s that reading would only be a waste of his time. As you might expect, his work did not support his thesis. Perhaps the same could be said for some of our radical young programmers. Perhaps there is something to be gained from reading other people’s programs—if only the amusement engendered by their bad examples. Perhaps if we want to understand how programmers program—to lift the veil of the programming mystique—we could fruitfully begin by seeing what is to be learned from the reading of programs.

— Gerald Weinberg, The Psychology of Computer Programming, Chapter 1

The meme that programming is a write-only skill is one that recurs from time to time. With relatively little software these days needing to be highly optimised, and developer time orders of magnitude more expensive than hardware, the dictum that software should be written primarily for humans to understand, and only secondarily for machines, is truer than ever. The context, and examples, in this book are rather quaint and almost humorous now (like noting that now that programmers actually work at a terminal they can just see what code does rather than having to read it offline).

But there is a great psychological point raised here too that I’ve never heard anyone talk about before and still holds as true today. Often in a software project, things are implemented in a clumsy, awkward, or otherwise non-standard manner. A lot of time this is because the programmer was unaware of the better way to do things, or needed to get on to working on other things as soon as the code “worked”, without having time to tidy it up. But sometimes there was as a good reason for the approach at the time it was written that is no longer true now (to work a limitation in a library being used that has long since been fixed, for example). If it’s in a relatively stable area of the codebase, it can languish there in that form for many years, until one day, needing to make a change nearby, a junior programmer will come in, see what to them is a needlessly complex part of code and congratulate themselves for knowing more than the programmer who originally wrote this nonsense. It’s not unusual, however, for that other programmer to now be their boss, and subtly contribute to building an unhealthy relationship there.


Computer Programming as a Human Activity

by Tony in * commentary, The Psychology of Computer Programming

This book has only one major purpose—to trigger the beginning of a new field of study: computer programming as a human activity, or in short, the psychology of computer programming. There are, by various estimates, hundreds of thousands of programmers working today. Each of them could be functioning more efficiently, with greater satisfaction, if he and his manager would only learn to look upon the programmer as a human being, rather than another one of the machines.

At the moment, programming—sophisticated as it may be from an engineering or mathematic point of view—is so crude psychologically that even the tiniest insights should help immeasurably.

— Gerald Weinberg, The Psychology of Computer Programming, Preface

This book was originally published in 1971. A decade ago there was a “Silver Anniversary Edition” published with additional commentary by the author from a perspective of 25 years on, but I don’t have that version; here I’m working from the original text.

There are very few computing-related books that are still relevant almost 40 years on. Hardware and software have changed beyond recognition multiple times, with the steady drive of Moore’s Law leading to computers that are a hundred million times more powerful. Many of today’s young programmers can barely conceive of a time before Google was the first port of call when something went wrong, never mind when computer time itself was so expensive that you had to do all your programming on paper, and, when you were ready, give it to an operator who would load it in for you and let you know the result! At the time this book was written, the debate was still raging over whether the new fangled approach of letting programmers actually work directly at the computer led them to grow lazy and adopt careless and inefficient work habits.

However, although the technical references in this book are often so dated they’re almost unintelligible, the observations on the human side of programming are still scarily accurate. Update the code snippets from FORTRAN to Ruby and the casual reader wouldn’t even realise for large chunks of the book that it wasn’t written last year. The reviews of the Silver Anniversary Edition seem almost to think this is a good thing, as it means the book is still relevant. To me it’s a hugely scary thing. How can we have learned so little in forty years? We should be looking back in horror at how programming was managed then, and the stories should sound as archaic as the technology.

In many ways, then, this book was a failure. The psychological aspects of programming are still poorly understood. Weinberg himself has developed many of the ideas much further in later works (such as the excellent Quality Software Management series), but these are even less widely read. But that doesn’t mean it should be abandoned. It’s every bit as important now as it was then, and the underlying promise quoted above still holds true: “even the tiniest insights should help immeasurably”.