The Psychology of Computer Programming

by Gerald M. Weinberg

Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples—both good and bad—to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many. And with the advent of terminals, things are getting worse, for the programmer may not even see his own program in a form suitable for reading.

did DHH read this for his software writing talk?

There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at code from the outside rather than by reading it. When we do read code, we find that some of it gets written because of machine limitations, some because of language limitations, some because of programmer limitations, some because of historical accidents, and some because of specifications—both essential and inessential.

many ways code gets to be the way it is, frequently not the original programmer's ideal approach...though it may appear that way years later

there's some evidence that the code that's read most frequently during software maintenance is not the best of examples. Mostly, that's why it is in maintenance in the first place.

this seems true!

Curiously, superior developers tend to find value with walkthrough and inspection processes while the merely clever do not. So, as always, the good get better and the bad get worse.

only the good engineers like design and code reviews.

If this observation holds true for programming, then any studies of the effect of certain programming practices should measure the effect on variability in production time—not

first, correctness, then minimize variance in dev time of subsequent projects, then minimize dev time of subsequent work, then efficiency

In his mathematical studies of genetic systems, R. A. Fisher derived a law that has often been called Fisher's Fundamental Theorem, a very significant name in view of the importance of Fisher's many other theorems. Fisher's Fundamental Theorem states—in terms appropriate to the present context—that the better adapted a system is to a particular environment, the less adaptable it is to new environments. By stretching our imagination a bit, we can see how this might apply to computer programs as well as to snails, fruit flies, and tortoises.

adaptability and efficiency often direct tradeoffs with one another. genetic algorithms research supports this hypothesis.

How many times have you ever thought, when writing a program, of some person in the future who might modify it? How many times have you ever cursed someone whose program you were modifying?

love this pair of questions. use quote in code review talk?

The passing years have validated the importance of variance in managing for quality. We are doing much better in the mean, but the variance remains, or has even grown, and customers are still dissatisfied.

mean dev time down for a given task, but variance the same or even worse. more frustrating to management than 25 years ago.

EGOLESS PROGRAMMING

cultural trait of good, healthy dev org. we should make it expllicit, perhaps not in these terms.

As a rough rule, three programmers organized into a team can do only twice the work of a single programmer of the same ability—because of time spent on coordination problems. Moreover, three groups of three programmers can do only twice the work of a single group—or four times the work of a single programmer—for the same reason. Thus, an eight-month project for a single programmer might be done in four months if we are willing to put three people to work on it or in two months if we are willing to allocate nine.

one "data point": triple the # of engineers, only double the throughput on shared project.

Back when I first wrote this book, I predicted "...attention to the subject of personality should make substantial contributions to increased programmer performance—whether that attention is paid by a psychological researcher, a manager, or the programmer himself." Even though I knew next to nothing about personality at the time, this turned out to be one of my most successful predictions.

is this true? tell more!

Someday, I suppose, I will pick up a used copy of this book and find that somebody has circled various letters to form R-U-B-Y-R-U-B-Y —and that's probably not the name of a girlfriend.

haahaah. when was this part written?!

As a matter of good practice, the test program should be constructed before the "fix" is made to the production program. In the first place, there will be an all too human tendency to forget about the problem once the production program is working correctly, so we must impose a little discipline on ourselves. Possibly more important, however, is the chance that by the mere act of constructing the test case we shall discover the problem.

red green testing. +1

In another study—one designed to compare the efficacy of two different programming languages—several of the participants complained that the turnaround was too good! They had been given special priority in order to facilitate the study, with the result that the measured average turnaround was 31 minutes from the time the job was passed through the window until the time the output was placed on the output table. The complaint was that if turnaround had been a little poorer, they would have spent a bit more time in making corrections and in perusing their output for additional errors. In a way, then, if the programmer has invested very little waiting time in a run, he may tend to value that run less—an observation which seems to hold for certain terminal systems as well. At the other extreme, very poor turnaround puts the programmer in an almost neurotic state when he submits a run.

on duration/delay in test run and effect on behavior: too fast and we get careless, don't scrutinize code as much. too long and we go crazy (or don't test enough)

The machine is, and always will be, the court of last resort on documentation disputes.

(I do recognize the now-ubiquitous FAQ documentation as the system I proposed back then for capturing, obviously, the most frequently asked questions.)

or stack overflow more like!