More on this book
Community
Kindle Notes & Highlights
The last thing I should wish to happen is to have anything said in this book taken as gospel—that
The material which follows is food for thought, not a substitute for it.
computer executives have always been aware of the human element in programming. Their concern, however, has usually been with eliminating, rather than understanding, the human element.
Nobody can seriously have believed that executives could read programs. Why should they? Even programmers do not read programs.
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.
Late at night, when the grizzled old-timer is curled up in bed with a sexy subroutine or a mystifying macro, the young blade is busily engaged in a dialogue with his terminal. No doubt it is much more thrilling to be face to face with the giant computer than merely wrapped in quiet contemplation of the work of others.
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.
how much coding is done because the programmer did not have full mastery of his computer, his language, or himself.
the programmer may be unaware of certain algorithms, or he may be unable to grasp a sufficiently large portion of the problem at one time to see that certain duplications may be avoided.
The prehistoric origins of certain pieces of code are almost beyond belief.
the larger a program grows, the more diffuse are the effects of particular historical choices made early in its life.
there will always remain the fact that, in most cases, we do not know what we want to do until we have taken a flying leap at programming it.
Specifications evolve together with programs and programmers. Writing a program is a process of learning—both for the programmer and the person who commissions the program.
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.
superior developers tend to find value with walkthrough and inspection processes while the merely clever do not.
we shall be hampered by our inability to measure the goodness of programs on an absolute scale.
we are never looking for the best program, seldom looking for a good one, but always looking for one that meets the requirements.
If a program doesn't work, measures of efficiency, of adaptability, or of cost of production have no meaning.
When there are multiple users, there are multiple specifications. When there are multiple specifications, there are multiple definitions of when the program is working.
it is not the mean length of estimated time that annoys people but, rather, the standard deviation in the actual time taken.
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.
When we ask for efficiency, we are often asking for "tight" coding that will be difficult to modify.
Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife or a handsome and humble husband.
if the compiler writer can choose 10 percent of the language which he will not implement, he can produce a 50 percent faster compiler.
with cost per unit of computation decreasing every year and cost per unit of programming increasing, we have long since passed the point where the typical installation spends more money on programming than it does on production work.
if the purpose of writing the program is to make money, then the one whose program makes the most money is certainly the best programmer—the best at realizing the requirements.
Many managers still seem to want everything, and fail to understand the importance of asking for intelligent trade-offs in order to get the best product they can.
Perhaps programming is too complex a behavior to be studied and must remain largely a mysterious process.
Sigmund Freud:* Psychoanalysis is learnt first of all on oneself, through the study of one's own personality. This is not exactly what is meant by introspection, but it may be so described for want of a better word. There is a whole series of very common and well-known mental phenomena which can be taken as material for self-analysis when one has acquired some knowledge of the method.
To be a "law," a principle must be explored so as to set limits to its application, because all laws have limits.
"Hawthorne Effect."
the act of observation itself which was producing the phenomenon being observed.
"participant observation," the anthropologist tries to make herself "invisible" to the people by becoming so much a part of the culture that she is not noticed, so that the culture can go on as if no outsider were there.
Another way of being "invisible" is to observe in ways in which the people observed actually have no possibility of knowing that they are under observation. Many such methods exist, and they may all be classified under the rubric of "unobtrusive measures."
Studies cost money, and in programming they cost more than in other areas of human behavior.
results obtained from trainees will be limited in their application, so that they may be useful only for the design of training programs.
It may be that the experiences in programming are so diverse as to make length of time a fruitless measure, or it may be that people don't all learn the same things from the same experiences.
forcing programmers to work in isolation is like trying to study the swimming behavior of frogs by cutting off their legs and putting those legs in the water to watch them swim.
Maxwell, the great physicist, once said, "To Measure is to Know,"
What Maxwell probably meant was "To know how to measure is to know," or even better, "To know what to measure is to know."
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 she 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.
Nobody, but nobody, should attempt to draw hard conclusions from such data as are being obtained in this field without studying the pitfalls which the behavioral scientists have already experienced.
there has been a great deal of psychological work on the subject of "problem solving" but this work in its details is not applicable to programming because the "problems" which are "solved" are simply too simple.
In programming, however, there is no right "solution"—we can be sure of that. But even if there were, we could be sure that we would not know it any better than our subjects.
The social science that provides us with the most useful overall model for computer programming is anthropology.
Faith, as Bertrand Russell pointed out, is the belief in something for which there is no evidence. Moreover, myths, as Ambrose Bierce once defined them, are the sacred beliefs of other people.
major problems are: • Using introspection without validation. • Using observations on an overly narrow base. • Observing the wrong variables, or failing to observe the right ones. • Interfering with the observed phenomenon. • Generating too much data and not enough information. • Overly constraining experiments. • Depending excessively on trainees as subjects. • Failing to study group effects and group behavior. • Measuring only what is simple to measure. • Using unjustified precision. • Transferring borrowed results to inapplicable situations.
perhaps the greatest mistake of all is overcaution.
I don't think programming is too complex a behavior to be studied, but it may be too complex to be studied in a laboratory.
I've observed that the "best" programmers are the most introspective.
