Add Psychology of Computer Programming workspace

MEMORY.md

@@ -1,6 +1,15 @@
 # Reading Memory Log
 Status board only. Details live in each chapter's memory.md.
 
+## The Psychology of Computer Programming — Gerald M. Weinberg
+- **Status**: In Progress
+- **Current Position**: Chapter 2 of 13 — Previewed, awaiting reading
+- **Current Chapter Memory**: /library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-memory.md
+- **Folder**: /library/The Psychology of Computer Programming/
+- **Source File**: /library/The Psychology of Computer Programming/source-file.pdf
+- **Structure**: /library/The Psychology of Computer Programming/book-structure.md (Silver Anniversary Edition; 13 chapters; OCR-checked image-only pages)
+- **Last Updated**: 2026-10-23
+
 ## Fanatical Prospecting — Jeb Blount
 - **Status**: In Progress
 - **Current Position**: Chapter 2 of 23 — Reading done — questions pending

library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-chapter-notes.md

@@ -0,0 +1,53 @@
+# The Psychology of Computer Programming — Chapter 01: Reading Programs
+- **Date Created**: 2026-10-23
+- **Status**: Complete
+- **Reading Span**: PDF pages 31-42
+
+---
+
+## 1. Pre-Reading Briefing
+- **Core Question**: What can reading a program reveal about programming as a human activity that running or evaluating its output cannot?
+- **Key Points to Watch For**:
+  - The difference Weinberg draws between executing code and reading it as a human-created text.
+  - His diagnostic question for each fragment of code: why is this piece here?
+  - The different sources of code structure he asks the reader to distinguish: machine, language, programmer, history, and specification.
+  - The way technical artifacts preserve earlier constraints, decisions, and organizational circumstances.
+  - What code review contributes to learning—and what makes programmers resist it.
+- **Context & Thread from Prior Chapters**: First chapter — nothing carried in.
+
+---
+
+## 2. Reading Review & Reflections
+- **Prompt Questions**:
+  1. In your own words, what can reading a program reveal about programming and its creators that merely running the program cannot?
+  2. Imagine you encounter a puzzling or apparently unnecessary fragment in an older codebase. How would you investigate whether it comes from a machine constraint, language constraint, programmer limitation, historical trace, or specification?
+  3. Which of those influences do you think most often misleads maintainers in modern software, and why?
+- **User Key Takeaways**:
+  1. "Why somthing was done in a certain way"
+  2. "youll need context of the issue and the machine it was used on"
+  3. "programmer limitation"
+- **Scaffolding & Feedback**: The reader identified the chapter's central purpose: reading code exposes why it took its present form. The instinct to seek context is correct, but the relevant context also includes the language and version, original specification, change history, and people—not only the issue and machine. Programmer limitation is a defensible modern concern, but strange-looking code should not be attributed to incompetence until vanished technical or historical constraints have been ruled out.
+- **Follow-Up Question**: What evidence would help distinguish a programmer limitation from a historical workaround that was reasonable when it was written?
+- **Follow-Up Answer**: "not sure but comments in the code and an understanding of what the progrm does helps"
+- **Follow-Up Feedback**: Comments and an understanding of behavior are useful evidence. Because comments can be incomplete or stale, corroborate them with version-control history, old requirements and issue records, tests, platform or language documentation from the period, and—when available—the original contributors. A programmer limitation becomes more likely only after showing that a simpler valid option existed at the time and the author apparently did not recognize it.
+
+---
+
+## 3. Chapter Synthesis
+- **Core Thesis**: Reading code as a human artifact reveals that its form comes from intertwined machine, language, programmer, historical, and specification forces—not simply from the problem it appears to solve.
+- **Key Concepts / Mental Models**:
+  - **Programs as readable artifacts**: Code is not merely input for a machine; it is a form of human writing from which programmers can learn by studying both strong and weak examples.
+  - **The causal reading question**: Ask, "Why is this piece here?" The question shifts attention from what code executes to the circumstances that produced it.
+  - **Five sources of code structure**: A fragment may reflect a machine constraint, language constraint, programmer limitation, historical trace, or specification. These causes can overlap.
+  - **Code archaeology**: Apparently irrational code may be the surviving residue of a once-rational workaround. Recover its original context before judging or removing it.
+  - **Specifications as evolving knowledge**: Implementation is not always the mechanical execution of a fixed specification; the program, programmer, and understanding of the desired result can develop together.
+  - **Review as deliberate practice**: Reading and discussing other people's code builds judgment, but its value depends on learning to distinguish good solutions from merely familiar ones.
+- **Notable Arguments & Evidence**:
+  - Weinberg repeatedly simplifies a small PL/I summation program by removing storage limits, language restrictions, and gaps in programmer knowledge. The exercise demonstrates that much of a program can encode its environment rather than its essential task (PDF pp. 31–39).
+  - A Social Security routine converted an unexpected `A` to `1` because an old keypunch had once produced that error. The temporary repair survived long after new validation made it appear pointless, illustrating how historical traces become maintenance puzzles (PDF pp. 37–38).
+  - Weinberg argues that specifications and programs often co-evolve because implementation teaches both developer and client what is actually wanted (PDF p. 38).
+  - In the Silver Anniversary comments, he maintains that program reading and technical review remain essential while warning that maintainers often encounter poor examples and accumulated historical residue (PDF p. 41).
+  - **Evidence limits**: The chapter is built mainly from professional observation and illustrative anecdotes, with examples tied to older hardware and PL/I/FORTRAN. The causal categories remain useful, but claims about prevalence should not be treated as modern quantitative evidence without validation.
+- **Updates to Prior Understanding**: As the opening chapter, this establishes the book's baseline lens: software should be examined not only as logic but also as evidence of human decisions made under particular technical and social conditions. The reader's instinct to use comments and observed behavior is useful, with the added safeguard that both should be corroborated before attributing strange code to programmer limitation.
+- **Weekly Action Item**: Choose one old or unfamiliar function. For each puzzling fragment, record its probable origin—machine, language, programmer, history, or specification—and the evidence supporting that classification. Check comments against version history, tests, requirements, and period-specific documentation before refactoring.
+

library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-memory.md

@@ -0,0 +1,29 @@
+# The Psychology of Computer Programming — Chapter 01 Memory: Reading Programs
+- **Stage**: Complete
+- **Next Step**: Prepare the Chapter 2 pre-reading briefing for "What Makes a Good Program?"
+- **Reading Span**: PDF pages 31-42
+- **Source Text**: /library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-source-text.md (the chapter's own words; read instead of the PDF)
+- **Full Record**: /library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-chapter-notes.md (read only if needed)
+- **Last Updated**: 2026-10-23
+
+## Carried-in Context (from earlier chapters)
+- First chapter — nothing carried in.
+
+## This Chapter
+- **Core Question**: What can reading a program reveal about programming as a human activity that running or evaluating its output cannot?
+- **Watch-For Themes**: Programs as texts for people; asking why each piece of code exists; machine, language, programmer, historical, and specification influences; code as evidence of its development context; the role of review in learning programming.
+- **Core Thesis**: Reading code as a human artifact reveals that its form comes from intertwined machine, language, programmer, historical, and specification forces—not simply from the problem it appears to solve.
+- **Key Concepts**: Program reading; "Why is this piece here?" causal analysis; machine/language/programmer limitations; historical traces; evolving specifications; review as learning.
+- **Notable Arguments / Evidence Limits**: A PL/I example is progressively simplified as constraints are removed; a Social Security patch shows obsolete workarounds surviving after their cause disappears; evidence is illustrative and anecdotal, drawn largely from older systems rather than controlled studies.
+- **Action Item**: Select one old or unfamiliar function and label each puzzling fragment by its likely origin, corroborating comments with history, tests, requirements, and platform documentation before changing it.
+
+## Reader State
+- **Pending Questions**: None
+- **Reader's Answers (paraphrase)**: Reading explains why code was written a certain way; investigation requires issue, machine, comments, and behavioral context; programmer limitations most often mislead modern maintainers.
+- **Misconceptions / Feedback Given**: Core idea is correct. Context also includes language/version, specification, change history, and people. Comments are useful but may be stale, so corroborate them with version history, requirements, tests, platform documentation, and original contributors when possible.
+- **Personal Threads**: Reader suspects programmer limitations are the dominant source of misleading modern code.
+
+## Open Threads
+- While reading, test whether Weinberg's categories still explain artifacts in modern codebases.
+- Distinguish genuine programmer limitations from historically rational decisions whose context has disappeared.
+

library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-source-text.md

@@ -0,0 +1,618 @@
+# The Psychology of Computer Programming — Chapter-01: Reading Programs
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 31–42
+- **Pages without text**: none
+- **Note**: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.
+
+---
+
+<!-- PDF page 31 -->
+| 
+READING 
+PROGRAMS 
+ome years ago, when COBOL was the great white programming 
+hope, one heard much talk of the possibility of executives being 
+able to read programs. With the perspective 
+of time, we can 
+see that this claim was merely intended to attract the funds of 
+executives who hoped to free themselves from bondage to their pro- 
+grammers. Nobody can seriously have believed 
+that executives could 
+read programs. Why should they? Even programmers do not read pro- 
+grams. 
+But isn’t it quite proper that only the machine should read programs? 
+Weren't the programs written for the machine? Yes and no. Even if we 
+were not concerned with program modification and with the interfaces 
+between programs, 
+reading programs might not be such a bad idea 
+from the point of view of learning about programming. 
+Programming 
+is, among other things, a kind of writing. One way to 
+5
+
+<!-- PDF page 32 -->
+6 
+Programming as Human Performance 
+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. In the old days—which in computing is not so long 
+ago—we had less easy access to machines and couldn’t afford to wait 
+for learning from actual machine runs. Turnaround was often so bad that 
+programmers would while away the time by reading each others’ pro- 
+grams. Some even went so far as to read programs from the program 
+library—which in those days was still a library in the old sense of the 
+term. 
+But, alas, times change. Just as television has turned the heads of the 
+young from the old-fashioned joys of book reading, so have terminals 
+and generally improved turnaround made the reading of programs the 
+mark of a hopelessly old-fashioned programmer. Late at night, when the 
+grizzled old-timer is curled up in bed with a sexy subroutine or a mystify- 
+ing 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. But is it more edifying? 
+A young novelist of our time was recently asked who were his 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 uegip 
+by seeing what is to be learned from the reading of programs. 
+AN EXAMPLE 
+In order to illustrate the joys and fruits of program reading, let us take 
+a tiny example gleaned from a professional lifetime of program reading— 
+one small program from among thousands. Suppose then that we come 
+across the PL/I program shown in Figure 1-1. What are we to make of 
+it? 
+We shall need a method of approach for reading programs, for, unlike 
+novels, the best way to read them is not always from beginning to end. 
+They are not even like mysteries, where we can turn to the penultimate
+
+<!-- PDF page 33 -->
+Reading Programs 
+7 
+XXX: 
+PROCEDURE OPTIONS(MAIN); 
+DECLARE 8(1000) FIXEN(7,2), 
+C FIXED(11,2), 
+(1, J) FIXED BINARY; 
+Cini): 
+DOT 
+har 
+ih TN 718; 
+GET LIST((B(J) 
+DO J = 1 TO 1N00)); 
+DO J = 1 TO 1000; 
+C's Ce BC) 
+END; 
+PUT LIST('SUM 
+IS ', C); 
+END XXX; 
+Figure 1-1 
+A program to be read. 
+page for the best part—or like sexy books, which we can let fall open 
+to the most creased pages in order to find the warmest passages. No, 
+the good parts of a program are not found in any necessary places— 
+although we will later see how we can discover crucial sections for such 
+tasks as debugging and optimization. Instead, we might base our reading 
+on a conceptual framework consisting of the origin of each part. In other 
+words, as we look at each piece of code, we ask ourselves the question, 
+“Why is this piece here?” 
+MACHINE LIMITATIONS 
+One of the reasons which account for pieces of code is that the ma- 
+chine on which the program is to be run is limited in some way relative 
+to the ideal machine for the problem. In our example, we see that a total 
+of 10,000 numbers are read into the computer and summed, but they 
+are read in batches of 1000. As the numbers are evidently punched in PL/I 
+LIST format, there is no reason why this division should be made, unless 
+perhaps the total storage was limited so that all 10,000 numbers could 
+not be stored at once. In other words, not having 40,000 bytes available,
+
+<!-- PDF page 34 -->
+8 
+Programming as Human Performance 
+the programmer had to break up his summing into smaller sections, which 
+led to the inclusion of an extra loop. If he had been able to store all 10,000 
+numbers, he might have written the program as shown in Figure 1-2. 
+Of course, when the programmer includes something that is intended 
+to overcome some limitation of the machine, he rarely marks it explicitly 
+as such. Although this omission adds to the intrigue of reading programs, 
+it does penalize the program when, for example, it is transferred to an- 
+other machine. The programmer may not even be aware that some of 
+his coding is intended to compensate for a limitation of the machine, in 
+which case he could hardly be expected to mark it. For instance, much 
+programming has to be done to overcome the limited precision of our 
+machines—or better still, the fact that they do not calculate with real 
+numbers but only with a limited set of the rationals. Yet programmers 
+tend to forget that these are limitations of the hardware and come to 
+think of them as facts of life. When we include such words as REAL in 
+Our programming languages, we compound the difficulty, and make 
+it 
+less likely that machine designers will become aware of the difficulties 
+this difference causes programmers. 
+Another area 
+in which machine 
+limitations 
+are 
+rife is intermediate 
+Storage. In the first place, we wouldn’t have intermediate storage at all 
+if we knew how to build the right kind of primary storage devices cheaply 
+enough. But short of that Nirvana, we still have to contend with a plethora 
+of drums, disks, tapes, and the like—all 
+of which 
+lead to enormous 
+XXX: 
+PROCEDURE OPTIONS(MAIN); 
+DECLARE A(10000) FIXEN(7,2), 
+CUPIXEDCII, 
+2), 
+J FIXED BINARY; 
+GET LISTC(ACJ) 
+DO J = 
+1 TO 10000)); 
+DO J = 1 TO 10000; 
+C=C 
++ ACJ); 
+END; 
+PUT LISTC'SUM 
+IS ', C); 
+END XXX; 
+Figure 1-2 
+Storage limitation removed.
+
+<!-- PDF page 35 -->
+Reading Programs 
+9 
+amounts of coding. Moreover, each device has peculiar timing character- 
+istics, modes of addressing, and storage capacity, and we find much 
+programming devoted 
+to overcoming 
+the less-than-optimum 
+(from the 
+programmer’s point of view) configuration we happen to have. 
+LANGUAGE LIMITATIONS 
+But machine limitations are not our primary concern here, for we are 
+seeking the human underpinnings of programming. A step closer to these 
+underpinnings 
+is the programming language—assuming 
+that nobody— 
+but nobody—programs in machine language anymore. One of the con- 
+sequences of moving up above machine language is that certain facilities 
+of the hardware may be lost to the user. An example of this type is the 
+end-of-file situation which exists in some FORTRAN systems. 
+In these 
+systems, the machine is perfectly able to recognize an end-of-file and 
+pass control to another section of the program, but the FORTRAN lan- 
+guage provides no such facility. Thus, the programmer has to resort to 
+devices such as the ‘‘end-of-file card”—an example in which both the 
+coding and the data have to be modified to overcome language limitations. 
+In our example, the language limitation is more subtle. PL/I provides 
+the programmer with a built-in function called SUM for taking the sum 
+of the elements of an array. In the original definition of the language, 
+however, at the time this program was written, SUM was a so-called 
+“mathematical” function, rather than an “arithmetic” function. What this 
+meant was that it assumed floating point input—and converted its input 
+to floating point if necessary. Aside from questions of efficiency, this 
+conversion could mean the loss of precision if the array—as in this ex- 
+ample—consisted 
+of FIXED DECIMAL numbers 
+with 
+fractional 
+parts. 
+Many programmers were distressed to discover that pennies were being 
+lost when they tried to balance accounts using SUM. The resulting protest 
+led to a redefinition of SUM as arithmetic generic, but, in the meantime, 
+it could not be used successfully on a problem such as our example. 
+Without this language limitation, the program could have been shortened 
+to read as in Figure 1-3. 
+In this figure, we have also eliminated the OPTIONS(MAIN) 
+on the 
+PROCEDURE statement, illustrating another form of language limitation— 
+the limitation of a particular implementation. This clumsy attribute was 
+only required in certain systems because of the interface with the oper- 
+ating system, which required that MAIN programs be handled somewhat 
+differently than subroutines. 
+Of course, PL/I is noted for its absence of silly little restrictions such as 
+abound in many other languages. To take just a few examples among
+
+<!-- PDF page 36 -->
+10 
+Programming as Human Performance 
+XXX: 
+PROCEDURE; 
+DECLARE A(10000) FIXED(7,2), 
+J FIXED BINARY; 
+GET LISTC(CACJ) 
+DO J’ = 1 TO 10000)); 
+PUT LIST('SUM 
+IS ', SUM(A)); 
+END XXX; 
+Figure 1-3 
+Using arithmetic generic sum. 
+many, consider all the extra coding that has been written in FORTRAN 
+because DO loops could not be counted backwards, because expressions 
+could not appear as increments or bounds of an iteration, or because 
+array subscripts had to start with one, or because only a small number 
+of subscript expressions were 
+possible. 
+Still, we may not feel these 
+limitations until they have been lifted from us, just as we often do not 
+know we are sick until we suddenly feel better. Therefore, it is reasonable 
+to expect that future languages will make us feel those limitations of 
+PL/I that are not detectable today. Notice that this is a psychological 
+question—one to which we shall have occasion to return. 
+PROGRAMMER LIMITATIONS 
+More directly psychological 
+is the question of how much coding is 
+done because the programmer did not have full mastery of his computer, 
+his language, or himself. For instance, in our example, the programmer 
+did not really understand array notation in PL/I—to the extent that he 
+was unaware of the possibility of putting an array name in a data list in 
+order to obtain all the elements of the array. Had he been familiar with 
+this feature—which was, after all, even 
+in FORTRAN—he might have 
+written the program shown in Figure 1-4. 
+XXX: 
+PROCEDURE; 
+DECLARE AC 10000) FIXED(7,2); 
+GET LIST(A); 
+PUT LISTC'SUM 
+1S *, SUM(A)); 
+END XXX; 
+Figure 1-4 
+Increased programmer awareness.
+
+<!-- PDF page 37 -->
+Reading Programs 
+11 
+There are, of course, programmer limitations other than merely not 
+knowing the full power of the language—vocabulary limitations, we might 
+say. For instance, 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. We shall 
+have much to say about these and other limitations as we proceed, for 
+these are obviously in the province of the psychology of programming. 
+HISTORICAL TRACES 
+We often find material in programs that might be accounted for under 
+one of the above categories but is really present because of the history 
+of the development of the program. For example, once the SUM function 
+is Changed to an arithmetic generic function, there 
+is no longer any 
+reason for the program in Figure 1-2 to appear. Nevertheless, things being | 
+what they are in the programming business, 
+it is unlikely that anyone 
+is going to delve into a working program and modify it just because the 
+definition of the SUM function has been changed. And so, some years 
+later, 
+a novice programmer who is given the job of modifying this pro- 
+gram will congratulate himself for knowing more about PL/I than the 
+person who originally wrote this program. Since that person is probably 
+his supervisor, an unhealthy attitude may develop—which, incidentally, is 
+another psychological reality of programming life which we shall have to 
+face eventually. 
+The prehistoric origins of certain pieces of code are almost beyond 
+belief. In one instance, two programmers digging into one of the basic 
+codes at the Social Security Administration discovered a curious artifact. 
+Whenever an input card with one of several origin codes was found to 
+have an “A” in a certain column, the ‘‘A’”’ was transformed into a ‘1.” 
+This was especially curious in view of the fact that only numeric values 
+could appear in this column—and there was a preedit program to ensure 
+that this was so. Still, the programmers were properly reluctant to modify 
+some coding whose purpose they did not understand, so they started an 
+inquiry. Eventually, they turned up a solution. 
+Several years earlier—which means several programmer generations 
+in some shops (which is another question of psychology, isn’t it!)—one of 
+the keypunches at one of the contributing district offices had developed 
+a bug which caused 
+it to punch a “1” as an “A” in just this column. 
+Since this was before the days of the preedit program, these mispunched 
+cards managed to penetrate the inner program and caused it to hang up. 
+By the time the problem was detected, there were an unknown number 
+of such cards in circulation, so the simplest course seemed to be to make
+
+<!-- PDF page 38 -->
+12 
+Programming as Human Performance 
+a “temporary” modification to the program. Once the patch was made, it 
+worked so well that everyone forgot about it—more psychology—and 
+there it sat until unearthed many years later by two archeologist pro- 
+grammers. 
+Not all historic code can be so easily differentiated as these examples 
+might imply. In particular, the larger a program grows, the more diffuse 
+are the effects of particular historical choices made early in its life. Even 
+the very structure of the program may be determined by the size and 
+composition of the programming group that originally wrote it—since the 
+work had to be divided up among a certain number of people, each of 
+whom had certain strengths and weaknesses. Indeed, the social organi- 
+zation of programming groups will be an area of major interest to us. 
+SPECIFICATIONS 
+When we look at the difference between Figures 1-1 and 1-4, we might 
+begin to believe that very little of the coding that is done in the world 
+has much to do with the problems we are trying to solve. Everything 
+considered, this would be a pretty fair statement of the situation—al- 
+though there probably is, in almost every program, some code which 
+actually does the work that was specified. Yet even 
+if we succeed in 
+extracting this kernel of the program, we must not be misled into the 
+illusion that we could have started with this kernel as a specification and 
+had some system take care of the other limitations. Aside from the obvi- 
+ous difficulties in determining a programmer’s intentions when he doesn’t 
+Know very much or in producing efficient code from a specification that is 
+written without the slightest understanding of what computers can do, 
+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 /earning—both for the programmer and the 
+person who commissions the program. Moreover, this learning takes place 
+in the context of a particular machine, a particular programming lan- 
+guage, a particular programmer or programming team 
+in a particular 
+working environment, and a particular set of historical events that deter- 
+mine not just the form of the code but also what the code does! 
+In a way, the most important reason for studying the process by which 
+Programs are written by people is not to make the programs more effi- 
+cient, more compact, cheaper, or more easily understood. Instead, the 
+most important gain is the prospect of getting from our programs what we 
+really want—rather than just whatever we can manage to produce in our 
+fumbling, bumbling way.
+
+<!-- PDF page 39 -->
+Reading Programs 
+13 
+SUMMARY 
+There are many reasons why programs are built the way they are, al- 
+though 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 pro- 
+grammer limitations, some because of historical 
+accidents, and some 
+because of specifications—both essential and inessential. But for what- 
+ever reason a particular piece of code gets inserted into the final product, 
+there are psychological aspects to that reason—which leads us to believe 
+that studying programming as human behavior will bear numerous and 
+not always expected fruits. 
+QUESTIONS 
+For Managers 
+1. If you are a first-line manager, are you capable of reading the programs 
+written by your programmers? Or did your ability to read programs 
+lapse with the previous generation of machines or languages? If you 
+are capable, do you read them? If you don’t, why not try it and see 
+what you find? 
+2. If you are a higher-level manager, are your first-line managers capable 
+of reading programs written by their programmers? Are you sure? Ask 
+the programmers themselves, then answer this question again. Then 
+find out if the first-line managers actually do read programs, even if 
+they are capable. Our surveys indicate that nine-tenths do not, for one 
+reason or another. Do you think it is possible for a first-line manager 
+to know how good his programmers are or how well they are doing 
+without occasionally reading their programs? 
+For Programmers 
+1. When was the last time you read somebody else’s program? Why has 
+it been so long? When was the last time somebody else read one of 
+your programs and discussed it with you? Was it your manager? 
+2. Borrow a program from the program library or from one of your friends. 
+Try to analyze it into pieces of code that are there for the various 
+reasons described in the text. What did you learn from this exercise? 
+3. Take one of your own programs written over a month ago, and analyze 
+it as in Question 2. What did you learn from this exercise?
+
+<!-- PDF page 40 -->
+14 
+Programming as Human Performance 
+BIBLIOGRAPHY 
+Bucholz, Werner, ed., Planning 
+a Computer System: Project Stretch, New York, 
+McGraw-Hill, 1962. 
+Computers too are made up of parts that get into them for various reasons. For 
+an excellent view of how computing machines come to be the way they are, this 
+book has not been surpassed. In addition, the book contains many insights into 
+the question of machine limitations on programming, since Stretch was intended 
+to be, among other things, a ‘“programmer’s machine” and thus eliminated many 
+of the things which we take for granted on other machine designs. 
+PL/I Language Log, IBM Corporation, Confidential File. 
+This may be hard to obtain, but now that IBM is no longer solely responsible for 
+maintaining the integrity of PL/I, it may be possible to see a copy. The Language 
+Log is a running record of the controversies and decisions that went into the 
+PL/I language we know today, and as such contains a marvelous education 
+in 
+how programming languages have been formulated. Hopefully, someone will pub- 
+lish parts of this Log in a suitably organized book. 
+Program Library of any user group or computer manufacturer. Your program library 
+contains a wealth of information. 
+Patronize it! 
+Weinberg, G. M., PL/I Programming: A Manual of Style, New York, McGraw-Hill, 
+1970. 
+Read this book if you want a lot more detail on the author’s ideas on how programs 
+come to look the way they do. 
+Gruenberger, 
+Fred, ed., Fourth Generation Computers: User Requirements and 
+Transition, Englewood Cliffs, N.J., Prentice-Hall, 1970. 
+Looking to the “fourth generation” with all the wisdom garnered from the first 
+three, several authors in this collection seem at last to be facing the problem of 
+the psychological needs of the computer user. Murray Laver traces the ways in 
+which designers, salesmen, and manufacturers have had more influence 
+in the 
+past than the people who were to use their products. Jacques Bouvard discusses 
+the need for more user orientation in the design of systems at the software level.
+
+<!-- PDF page 41 -->
+Silver Anniversary Notes 
+Comments on 
+Chapter 1: 
+Reading Programs 
+Not much has changed here. 
+The reading of programs is still the key to 
+understanding how we make programs. One improvement is emerging: libraries 
+of works to study—such as class libraries—though these generally lack the criti- 
+cal commentary that would make them a more valuable training resource. 
+However, the patterns movement is addressing this need, but much work must 
+be done: One of the obstacles organizations claim keeps them from moving to a 
+new technology is the effort required to understand the class libraries that come 
+with the development environments. 
+One change is the growth of historical traces in code. 
+After all, they’ve had 
+twenty-five more years to accumulate, and they have definitely accumulated. 
+This accumulation is bad for software maintenance, but possibly good for the 
+study of programming as human behavior, assuming we have access to these 
+traces and some documentation suggesting how the code got that way. 
+However, the code that’s read most frequently during software maintenance is 
+usually not the best of examples. Mostly, that’s why it is in maintenance in the first 
+place. Reading code won't help much if the reader has no sense of what’s good and 
+what’s bad. That much hasn’t changed in twenty-five years. 
+‘But why is it so hard for developers to submit their work for review by others 
+or to try to improve their own skills by reviewing the work of others? 
+Curiously, 
+superior developers tend to find value with walkthrough and inspection process- 
+es while the merely clever do not. 
+So, as always, the good get better and the 
+bad get worse.
+
+<!-- PDF page 42 -->
+r 
+Wl 
+eh 
+et 
+ae 
+wae 
+ws -) 
+ee 
+a 
+poner: ie ial 
+| 
+De ee 
+oe 
+: 
+7 
+ay 
+mh: ee t4 
+anes st adie the ge 
+a i 
+rR tay cueing: 
+ah 
+4 
+sfyet 
+Gueerd tel. 
+°4 eceiie) ne 
+_ Apsalh 
+_e 
+hgh 
+Alii 
+ort toe Sh hag 
+My ‘ * iy Bical a 
+ft t s € 
+(ook 
+: 
+“ain 
+ieee 
+extn 
+| 
+rae, Pade tephra 
+Pepe 0 seta Att B 
+al 
+: 
+4 Pye Hh, ae 
+oe, 
+am 
+ee 
+ee ne 
+bs 
+’ 
+f year 
+othe p 
+1 
+i 
+; 
+VeRO 
+Dy | 
+£ Mure! 
+on Ty 
+aw 
+Fore, 
+eoreit 
+9 
+to) 
+vy 
+detuit 
+cor relates iw on New 
+i yod om ie see ig 1G OF ibysey ety “pen b 
+Rise 
+i ety, 
+oni t Jaen 
+“Ay pia ie 
+an SPOR 
+Se 
+ie off Bae She 
+oie a, 
+leah a ioe esto 
+ag a 
+a 
+SALGtee QUE 
+se 
+se went. g Cort edment ow 
+See 
+. 
+Vit Ow Bier ne Deoryiay erieer ROS, Hiei avert? “n 
+Tt 
+VSR 
+’ 
+“a, 
+Deg 
+as 
+% 
+ahi. 
+> bi g ie ay Af nt eat pa wy 2 Magma eee L ayy aL 
+BY . 
+ah 
+‘| eee reba Larakoranggn, 
+ot 
+apne 
+ges, 
+08, Bh ue seiapi ye 
+* ainamnonivn prapeini anttn 
+bart av’ yee) ty wae Shay A omy lenbotait ws (Avg en a 6 
+; 
+x 
+heleh« wags Yaitey oven ver! ble oleliumucs of 2168Y momo 
+hing y 
+ati sot boop yicieegn RIG .eoonfatian eswites 10) bed al | 
+mOOe 
+@ 
+azar ol ezaocs eyed ew gninuees. roared nemud 
+ey Qaimme pow 
+vee te oi og ico ari wor! piiissggue NolEmaMWaab amoe bf 
+a anaane) eit onenieg grinds yiaupar Jac bath eat aboo art aBve 
+KR 
+Oe 7 Con 
+eteKRNT 
+Am nS yeti Saat oe a ea 
+bite bone eetw er oamR 8 
+aM bm 
+er 1 
+autn le FIBH Boo 28 = 
+Sateen ii. si 
+‘ert We 
+TON oF Ha Men 
+2k ye 
+Nlewrol wx ape age cds os och 
+| 7” 
+f even 
+OY 
+= 
+¥. 
+ae 
+id 
+iB 
+ch 
+ie 
+J

library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-chapter-notes.md

@@ -0,0 +1,33 @@
+# The Psychology of Computer Programming — Chapter 02: What Makes a Good Program?
+- **Date Created**: 2026-10-23
+- **Status**: In Progress
+- **Reading Span**: PDF pages 43-56
+
+---
+
+## 1. Pre-Reading Briefing
+- **Core Question**: Can a program be judged "good" apart from its situation, or must quality be evaluated through competing requirements and stakeholder priorities?
+- **Key Points to Watch For**:
+  - How Weinberg defines or complicates the idea that a program "works."
+  - Why delivery time and schedule predictability may matter independently of technical elegance.
+  - The tension between adaptability and optimizing for one particular environment.
+  - How an efficiency measure can move costs between the computer, programmer, operator, and user.
+  - Whose requirements or value judgments ultimately determine whether a program is good.
+- **Context & Thread from Prior Chapters**: Chapter 1 treated code as evidence of machine, language, programmer, historical, and specification forces. Chapter 2 carries that contextual lens from explaining a program's form to judging its quality. The reader will continue resisting premature judgments—especially programmer-blame—until the relevant constraints and history are understood.
+
+---
+
+## 2. Reading Review & Reflections
+- **Prompt Questions**: Pending
+- **User Key Takeaways**: Pending
+- **Scaffolding & Feedback**: Pending
+
+---
+
+## 3. Chapter Synthesis
+- **Core Thesis**: Pending
+- **Key Concepts / Mental Models**: Pending
+- **Notable Arguments & Evidence**: Pending
+- **Updates to Prior Understanding**: Pending
+- **Weekly Action Item**: Pending
+

library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-memory.md

@@ -0,0 +1,32 @@
+# The Psychology of Computer Programming — Chapter 02 Memory: What Makes a Good Program?
+- **Stage**: Previewed — awaiting reading
+- **Next Step**: Wait for the reader to finish Chapter 2 and say "done" or request `/review`; then ask 2-3 open-ended review questions.
+- **Reading Span**: PDF pages 43-56
+- **Source Text**: /library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-source-text.md (the chapter's own words; read instead of the PDF)
+- **Full Record**: /library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-chapter-notes.md (read only if needed)
+- **Last Updated**: 2026-10-23
+
+## Carried-in Context (from earlier chapters)
+- Code is a human-created text whose form cannot be explained by behavior alone.
+- Ask "Why is this piece here?" and test five possible influences: machine, language, programmer, history, and specification.
+- Apparently poor code may preserve a once-rational workaround; recover context before judging it.
+- Specifications and programs can evolve together as developer and client learn what is actually needed.
+- The reader sees programmer limitation as a major modern risk but will corroborate that judgment with comments, behavior, history, tests, requirements, and platform evidence.
+
+## This Chapter
+- **Core Question**: Can a program be judged "good" apart from its situation, or must quality be evaluated through competing requirements and stakeholder priorities?
+- **Watch-For Themes**: What "working" means; correctness for one versus many users; delivery time and predictability; adaptability versus specialization; ambiguous efficiency measures; who receives value and who bears cost.
+- **Core Thesis**: Pending
+- **Key Concepts**: Pending
+- **Notable Arguments / Evidence Limits**: Pending
+- **Action Item**: Pending
+
+## Reader State
+- **Pending Questions**: None
+- **Reader's Answers (paraphrase)**: None for this chapter
+- **Misconceptions / Feedback Given**: None for this chapter
+- **Personal Threads**: Continue testing programmer limitation against historical context rather than assuming it.
+
+## Open Threads
+- How should program quality be judged when different contexts reward different tradeoffs?
+- Watch for criteria that appear desirable alone but become contradictory when demanded together.

library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-source-text.md

@@ -0,0 +1,632 @@
+# The Psychology of Computer Programming — Chapter-02: What Makes a Good Program?
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 43–56
+- **Pages without text**: none
+- **Note**: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.
+
+---
+
+<!-- PDF page 43 -->
+PROGRAM? 
+f we plan to study programming as a human activity, we are going to 
+have to develop some measures of programming performance. That 
+is, we are going to have some idea of what we mean when we Say that 
+one programmer is better than another, or one program is better than 
+another. Although we all have opinions on these questions, we shall find 
+that the answers are not as simple as we might wish. For programming is 
+not just human behavior; it is complex human behavior. 
+Consider our programming example once again. By analyzing Figure 
+1-1 rather thoroughly, we discover that only a small portion of it—no 
+more than 20 percent—is directed 
+at meeting the problem specifica- 
+tions. Of the other 80 percent, much, if not most, can be eliminated not 
+by physical change but by psychological change. In fact, even the ques- 
+tion of a limited storage could have been dealt with by an appropriate 
+virtual machine, so that even machine limitations can be overcome by 
+proper psychological design. 
+15
+
+<!-- PDF page 44 -->
+16 
+Programming as Human Performance 
+The program in Figure 1-1, though small, is typical in the percentage of 
+coding that is actually devoted to solving the given problem. Because 
+people do not read programs, few are aware of how common this situa- 
+tion is. But common it is, and it gives us much scope for improvement in 
+our programming. Still, there is more to the question of good program- 
+ming than measuring the percentage of extraneous—or at least peripheral 
+—code. Indeed, we cannot really measure a program by itself and say 
+whether it is good or bad. 
+Most programmers feel that there is such a thing as good programming. 
+Although this feeling may be valid, it does not follow that there is such a 
+thing as a good program. Not, at least, in the sense that we can study 
+the program out of the context in which it was developed and in which 
+it will be used and declare it to have a goodness of 83.72 percent. 
+Consider Figure 1-1. Is it a good program? It is a clumsy program, 
+perhaps, but that is only part of the mark. After all, we only knew it was 
+clumsy because we read it, and for the ordinary program, nobody is ever 
+going to read 
+it, so grace is hardly an absolute measure of program 
+goodness. Is it an efficient program? We can hardly answer this question 
+without knowing the machine, the compiler, and the cost situation under 
+which it will be run. Was it done on time? What did it cost? Does it meet 
+specifications? We cannot know these things merely by looking at the 
+code. 
+In our studies of the psychology of programming, we shall be hampered 
+by our inability to measure the goodness of programs on an absolute 
+scale. But can we perhaps measure them on a relative scale—can we say 
+that program A is better or worse than program B? Unfortunately, we will 
+generally not even be able to do that, for several reasons. 
+First of all, 
+when is there ever another program with which to compare? And when 
+there is, as in the case of, say, 
+a FORTRAN compiler, how can we agree 
+on the relative importance of the different attributes of the program. Is a 
+compiler that quickly compiles slow code better than one that slowly 
+compiles quick code? 
+But still, aren't there times when we can make a relative ranking? 
+Isn’t a compiler that quickly compiles quick code better than one that 
+Slowly compiles slow code? We have to admit that sometimes such com- 
+parisons can be made—although we must not be too hasty in making 
+them. There are dimensions of compiler performance other than speed. 
+There are diagnostics, scope of language covered, reliability of object 
+code, and execution time monitoring, to mention a few. Only rarely will 
+we find two programs so sufficiently similar that they can be compared 
+point by point—and then find one superior on all points. 
+More often, then, we will be doing evaluation of programs not with 
+respect to one another but with respect to a situation—a total situation
+
+<!-- PDF page 45 -->
+What Makes a Good Program? 
+17 
+—in which they are developed. Looking honestly at the situation, we are 
+never looking for the best program, seldom looking for a good one, but 
+always looking for one that meets the requirements. 
+SPECIFICATIONS 
+Of all the requirements that we might place on a program, first and 
+foremost is that it be correct. in other words, it should give the correct 
+outputs for each possible input. This is what we mean when we Say that a 
+program ‘‘works,”’ and it is often and truly said that “any program that 
+works is better than any program that doesn’t.” 
+An example may serve to drive home this point to those whose minds. 
+are tangled in questions of efficiency and other secondary matters. A 
+programmer was once called to Detroit to aid in the debugging of a new 
+program—one that was to determine the parts requirements to build a 
+certain set of automobiles. The input to the program was a deck of cards, 
+each card representing a purchase order for an automobile, with differ- 
+ent punches representing the different options selected by the customer. 
+The program embodied the specifications relating the various options to 
+the parts that would be needed. For instance, the choice of upholstery 
+for the rear seat might be determined by such factors as body color, 
+body style, options for deluxe or leatherette upholstery, and whether or 
+not the car was air conditioned. The air-conditioning option is a good 
+example of the basic complexity of the problem, for though to an un- 
+trained eye the choice of air conditioning might have no connection with 
+the choice of rear seat upholstery, it might very well require spaces for 
+extra ducts. In general, then, each option might have some effect on the 
+choice of parts made, so the determination of parts requirements was an 
+excellent job for the computer. 
+Unfortunately, when this programmer arrived on the scene, the basic 
+approach to the problem had long been settled—and settled badly. Each 
+option—as 
+it affected 
+each choice—was 
+reflected 
+as 
+an_ 
+individually 
+programmed test and branch in the program. In a way, the program was 
+an enormous tree, with more than 5000 branches, representing the de- 
+cisions leading to part selection. Cast in this form—and with 16 program- 
+mers working at the same time—it was impossible to debug, as each and 
+every case had to be tested separately. To test the program, a particular 
+card would be put in and the output would be observed. When our 
+programmer arrived, things were so bad that typical cards were calling 
+for the production of cars with eight tires, no engine, and three sets of 
+upholstery. In short, a disaster. 
+As is usual with programming disasters, nobody recognized it as such.
+
+<!-- PDF page 46 -->
+18 
+Programming as Human Performance 
+Instead, the whole crew had gone on double shift to get out the bugs, and 
+new programmers, including our hero, were brought in from all over the 
+country. Naturally, this led to worse confusion than ever, and our pro- 
+grammer, after a few days, determined that it was hopeless business— 
+and in any case not reason enough to be away from his family and 
+working night and day. He was roundly condemned for his uncooperative 
+attitude but was allowed to leave. 
+While on the plane, he had his first opportunity in a week to reflect 
+calmly. He immediately saw the error in the approach and perceived that 
+a much better approach would be to divide the work into two phases. 
+The main operational program would simply loop through a set of spe- 
+cially constructed specifications tables, so that all decisions would be 
+made with a single test reapplied to different parts of the table. In that 
+way, the program was at least assured to produce the right number of 
+tires, engines, and so forth. The tables themselves would be compiled 
+from input written in essentially the form of the engineering specifications. 
+This would allow the engineering personnel, rather than the programmers, 
+to check the specifications, and also permit one part of the specification 
+to be changed without changing all parts further down a decision tree. 
+By the time he got off the plane, he had coded the two programs. It was 
+a day’s work to check them out, and another two days’ work with the 
+local assembly plant engineers to create the specifications in input form. 
+After a week’s testing in the plant, he was about to return to notify De- 
+troit of the news when he got a telegram saying that the project had been 
+cancelled—since the program was impossible to write. 
+After a quick call and a plane trip, he was back in Detroit with his 
+version of the program. A demonstration 
+to the executives convinced 
+them that the project could continue, and then he was asked to make a 
+presentation to the rest of the programmers. Naturally, they were a rather 
+cool audience—a phenomenon to which we shall return in our discussions 
+—but they sat quietly enough through his explanation of the method. Even 
+at the end, there was a lack of questioning—until the original creator of 
+the old system raised his hand. 
+“And how long does your program take?” he asked—emphasizing the 
+possessive. 
+“That varies with the input,” was the reply, ‘but on the average, about 
+ten seconds per card.”’ 
+“Aha,” was the triumphant reply. “But my program takes only one 
+second per card.” 
+The members of the audience—who had, after all, all contributed to 
+the one-second version—seemed relieved. But our hero, who was rather 
+young and naive, was not put down by this remark. Instead, he calmly 
+observed, “But your program doesn’t work. If the program doesn’t have
+
+<!-- PDF page 47 -->
+What Makes a Good Program? 
+19 
+to work, | can write one that takes one millisecond per card—and that’s 
+faster than our card reader.”’ 
+This observation—though 
+it undoubtedly failed to win our hero any 
+friends—contains 
+the fundamental 
+truth upon which 
+all programming 
+evaluation must be based. If a program doesn’t work, measures of effi- 
+ciency, of adaptability, or of cost of production have no meaning. Still, we 
+must be realistic and acknowledge that probably no perfect program was 
+ever written. Every really large and significant program has “just one 
+more bug.” Thus, there are degrees of meeting specifications—of ‘‘work- 
+ing’ —and evaluation of programs must take the type of imperfection into 
+account. 
+Any compiler, for example, is going to have at least “‘pathological’’ pro- 
+grams which it will not compile correctly. What is pathological, however, 
+depends to some extent on your point of view. If it happens in your pro- 
+gram, you hardly classify it as pathological, even though thousands of 
+other users have never encountered the bug. The producer of the com- 
+piler, however, must make some evaluation of the errors on the basis of 
+the number of users who encounter them and how much cost they incur. 
+This is not always done scientifically. Indeed, 
+it often amounts to an 
+evaluation of who shouts the loudest, or who writes to the highest execu- 
+tive. But whatever system is chosen, some bugs will remain, and some 
+people will be unhappy with the same compiler that satisfies thousands. 
+In effect, then, there is a difference between a program written for one 
+user and a piece of ‘‘software.’’ When there are multiple users, there are 
+multiple specifications. When there are multiple specifications, there are 
+multiple definitions of when the program is working. In our discussions of 
+programming practices, we are going to have to take into account the 
+difference between programs developed for one user and programs de- 
+veloped for many. They will be evaluated differently, and they should be 
+produced by different methods. 
+SCHEDULE 
+Even after questions of meeting specifications have been set aside, the 
+question of efficiency is still not uppermost. One of the recurring problems 
+in programming is meeting schedules, and a program that is late is often 
+worthless. At the very least, we have to measure the costs of not having 
+the program against any potential savings that a more efficient program 
+would produce. In one noteworthy case, the customer of a software firm 
+estimated that the linear programming code being developed would save 
+more than one million dollars per month in the company’s oil refining 
+operations. Even one month’s delay in schedule would result in a loss that
+
+<!-- PDF page 48 -->
+20 
+Programming as Human Performance 
+could not be recovered 
+if the program were run free of charge for ten 
+years. 
+Losses from late delivery of programs are not always so severe, but 
+even were the costs negligible, there seems to be, in the United States, 
+at least, an incredible amount of annoyance when schedules are not met. 
+In fact, the average programming manager would prefer that a project 
+be estimated at twelve months and take twelve than that the same project 
+be estimated at six months and take nine. This is an area where some 
+psychological study could be rewarding, but there are indications from 
+other situations that it is not the mean 
+length of estimated time that 
+annoys people but, rather, the standard deviation in the actual time taken. 
+Thus, most people would prefer to wait a fixed ten minutes for the bus 
+each morning than to wait one minute on four days and twenty-six minutes 
+once a week. Even though the average wait is six minutes in the second 
+case, the derangement caused by one long and unexpected delay more 
+than compensates for this disadvantage. 
+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 just mean time as most studies cur- 
+rently do. We shall try to estimate this effect in all our subsequent dis- 
+cussions. 
+ADAPTABILITY 
+Having disposed of the questions of meeting specifications and sched- 
+ules, we might suppose that we had finally arrived at the question of 
+efficiency as a measure of the goodness of programs. Without begging the 
+question of relative importance of the two factors, however, it will prove 
+advantageous first to dispose of the factor of adaptability of a program. 
+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 be- 
+fore 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 pro- 
+grammers, who know full well that programs will inevitably be modified,
+
+<!-- PDF page 49 -->
+What Makes a Good Program? 
+21 
+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 Pharoahs’ tomb against 
+all 
+in- 
+truders? 
+There are answers to these questions, and they lie in the direction of 
+our psychological investigations. But our job for the moment is not to 
+answer them, but merely to raise them and remind ourselves of their 
+importance 
+in any discussion 
+of what makes good programming. A 
+related question is, of course, documentation, for why do we document 
+a program 
+if not to render 
+it more easily modifiable? We would 
+all 
+agree that the quality of documentation and the ease of making modifi- 
+cations, both planned and unplanned, should count heavily in any grad- 
+ing of a program, 
+or of the programmer who writes that program. We 
+would all agree further, then, that any improvement here to be gained 
+from psychological investigations will be well worth the effort. 
+But, a word of caution before we proceed to the question of efficiency. 
+Adaptability is not free. Sometimes, to be sure, we get a program that 
+happens to be adaptable as well as satisfactory in all other ways, but we 
+generally pay for what we get—and often fail to get what we pay for. In 
+his mathematical studies of genetic systems, R. A. Fisher derived a law 
+that has often been called Fisher's Fundamental Theorem, a very signi- 
+ficant 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 imagina- 
+tion a bit, we can see how this might apply to computer programs as 
+well as to snails, fruit flies, and tortoises. 
+For a program to be efficient, it must take advantage of the peculiarities 
+of the problem and the machine on which it is to be run. Programs that 
+ignore the structure of the machine do so at the risk of incurring heavy 
+cost penalties, and programmers who can exploit special situations in a 
+problem are the ones who can speed things up and make them smaller. 
+One peculiar example, not entirely untypical, of this type of programming 
+was an assembly program that employed a special technique for looking 
+up operation codts to be translated. The programmer had observed—or 
+figured out—that there was one number which, when used to multiply the 
+operation code bit pattern interpreted as numeric, yielded an almost solid 
+and completely unduplicated 
+list of addresses. Using this multiplier, he 
+was able to effect a compact and equally fast transformation from sym- 
+bolic codes to machine language. 
+The programmer was much congratulated for this ingenuity—the ex- 
+ample was displayed to several generations of programmers as a proto- 
+type of the kind of work they should be doing. Sadly, however, 
+this
+
+<!-- PDF page 50 -->
+22 
+Programming as Human Performance 
+section of code did not have a very long life, for, as so frequently happens, 
+the operation code repertoire of the machine was expanded. When a 
+dozen or so codes had been added to the set, the old multiplier no longer 
+had the same desirable properties of compactness and uniqueness. In 
+fact, no multiplier could be found that would work in this way for the 
+new codes. 
+The outcome of attempts to find a new multiplier was to abandon this 
+special technique for a more general hash table search—one that allowed 
+for the existence of duplicates. Unhappily, the old technique was not 
+abandoned 
+before a great deal 
+of effort had been expended 
+on the 
+attempt to adapt it to the changed circumstances. This proved to be time 
+wasted. In retrospect, the savings in time of the specialized technique 
+never paid in its lifetime for the extra cost of fooling around when the 
+new codes were added. If a general hash table method had been used in 
+the first place, somewhat lower efficiency would have been the result; 
+but—and 
+this is the “but” that makes the example—the modification 
+would have been entirely trivial. In fact, essentially no modification would 
+have been required except the addition of the new codes to the appro- 
+priate places in the table. 
+This example could be supplemented with hundreds of others, but the 
+point would be the same. When we ask for efficiency, we are often asking 
+for “‘tight’’ coding that will be difficult to modify. In terms of higher-level 
+languages, we often descend to the machine-language level to make a 
+program more efficient. This loses at least one of the benefits of having 
+the program in the higher-level language—that of transportability between 
+machines. In fact, it has the effect of freezing us to a machine or imple- 
+mentation that we have admitted by our very act is unsatisfactory. 
+However, the same managers who scream for efficiency are the ones 
+who tear their hair when told the cost of modifications. Conversely, the 
+managers who ask for generalized and easily modified programs are wont 
+to complain when they find out how slow and spacious these programs 
+turn out to be. We must be adult about such matters: neither psychology 
+nor magic is going to help us to achieve contradictory goals simultane- 
+ously. Asking for efficiency and adaptability in the same program is like 
+asking for a beautiful and modest wife. Although beauty and modesty 
+have been known to occur in the same woman, we’ll probably have to 
+settle for one or the other. At least that’s better than neither. 
+EFFICIENCY 
+Measuring the true efficiency of a program 
+is not the simple task it 
+first seems. In the first place, efficiency is not always measured simply 
+in terms of time on the computer, for it is often possible to trade time on
+
+<!-- PDF page 51 -->
+What Makes a Good Program? 
+23 
+the computer for time before and after the computer run. For example, a 
+commonly used measure of the speed of a compiler is the number of 
+cards per minute it processes. If we use this measure to compare an 
+assembly program with, say, 
+a FORTRAN compiler, the assembly is likely 
+to appear more efficient, since each input card carries less information. 
+Sometimes compilers are compared on the basis of the number of ma- 
+chine instructions produced per minute, but this measure exposes us to 
+the danger of giving credit to a compiler simply because 
+it is verbose 
+in the production of object code. 
+A compiler, of course, 
+is a special kind of beast anyway, since we 
+must measure the efficiency of the code produced as well as that of the 
+compilation process. Still, since compiler efficiency is a subject of much 
+discussion, it may be worthwhile to pursue this example to illustrate how 
+easily we can be misled on efficiency questions. Consider, for instance, 
+the comparison of two compilers for the same language in terms of the 
+“cards per minute’”’ measure. The first pitfall here lies in the term “same 
+language.”’ Very few compilers handle exactly the same language, so if 
+there 
+is any difference between 
+the two, we will have to adjust the 
+efficiency obtained from cards per minute to account for the difference 
+in value of the two languages. 
+The effect of slight differences 
+in source language on compiler effi- 
+ciency can be striking. Typically, 
+if the compiler writer can choose 10 
+percent of the language which he will not implement, he can produce a 
+50 percent faster compiler. Unfortunately, which 10 percent is chosen 
+differs from one machine and one compiling technique to the other, so 
+that language designers cannot simply provide “more efficient’ subsets 
+to be implemented. 
+Similar improvements in efficiency are possible from similar relaxation 
+of specifications in other areas. Indeed, if our primary concern in a par- 
+ticular application 
+is efficiency, the first step should always be to look 
+for areas in which the specifications can be changed to suit computer 
+efficiency rather than user convenience. Of course, computer time is not 
+the only cost element in a typical project. People time also costs money. 
+Thus, we can leave certain crossfootings to be done by the recipient of 
+a report, but we may only be saving computer time at the expense of 
+executive time with paper and pencil. We may decide quite rationally to 
+make this choice, but more often the choice is made without the execu- 
+tive having anything to say about it. 
+Trimming the external specifications can even have the opposite of the 
+intended effect on computer time used. If, for example, a great deal of 
+manual handling of input has been left in the system to simplify the com- 
+puter run, we may find ourselves paying more in reruns than we saved 
+in single-run efficiency. This effect is rather common when comparing 
+two compilers which, even though they handle identical language, differ
+
+<!-- PDF page 52 -->
+24 
+Programming as Human Performance 
+in the diagnostics and execution monitoring they produce. 
+If we save 
+20 percent in raw compile time by eliminating or trimming error checking, 
+we had better be sure that the user will not find himself making 40 
+percent more runs to get the same amount of information. 
+As hazardous as it is to make simple measures of efficiency in a single- 
+machine, simple-scheduler environment, it is child’s play compared with 
+the difficulties of obtaining meaningful efficiency estimates 
+in a multi- 
+processing or multiprogramming environment. 
+Is it better, for instance, 
+to occupy 40K bytes of main storage for one hour or 80K bytes for 30 
+minutes? The answer to this question depends on the situation in the 
+computer at the time the job is run—and may change each time the job 
+is run. For example, one day it may be possible to add a 40K job to the 
+machine load without affecting the performance of the other jobs by one 
+second; yet the next day the same 40K job may lock out another job for 
+the full hour. 
+Running on systems capable of dynamic load adjustment may alleviate 
+some of the instabilities in multiprogram performance that we often see 
+today. It may very well be that, as with schedules for programming, what 
+the user wants is not a small mean time to execute his program but a 
+small standard deviation, so he can plan his work reasonably. If this is 
+true, the entire schedule from origin to destination of the work must be 
+considered, not just the “time on the computer.” 
+We may be moving toward 
+a computing environment 
+in which the 
+best programs are those that retain the ability to be run in various sizes 
+of main memory, on various machine configurations. Such a program 
+may not be very efficient on any one of the configurations—considering 
+Fisher’s Fundamental Theorem applied in the inverse sense—but may 
+lead to more consistent turnaround performance because 
+it will never 
+find itself waiting for just the correct slot in the day’s schedule. Machines 
+with virtual memories give us this kind of flexibility without special pro- 
+gramming, although there are indications that performance improvements 
+can be obtained even in this environment by taking special character- 
+istics into account. 
+For instance, if we know the page size of our system, we can avoid 
+excessive paging by tailoring our program sections to fit into single 
+pages and not to cross page boundaries except at logical breaks in the 
+program. 
+If we do this, however, the program becomes somewhat less 
+well adapted for running in a system with a different page size. Similarly, 
+we can choose an algorithm that will require no more and no less page 
+Space than is commonly allowed by our system; but again, this kind of 
+program will fail to take advantage of extra page space and will give 
+the worst possible performance in a system with a smaller page space. 
+What all of this means is that efficiency is becoming a clouded issue
+
+<!-- PDF page 53 -->
+What Makes a Good Program? 
+25 
+in computing. Moreover, 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. This imbalance 
+is 
+even more striking when 
+all the work improperly classified 
+as ‘‘pro- 
+duction” 
+is put under the proper heading of “debugging.” But by any 
+measure, 
+the imbalance 
+exists. And grows. 
+And 
+so we expect 
+that 
+with each passing year we will hear less and less about efficiency—and 
+more and more about effectiveness. 
+SUMMARY 
+The question of what makes a good program 
+is not a simple one, 
+and may not even be a proper question. Each program has to be con- 
+sidered on its own merits and in relation to its own surroundings. Some 
+of the important factors are: 
+1. Does the program meet specifications? Or, rather, how well does it 
+meet specifications? 
+2. Is it produced on schedule, and what is the variability in the schedule 
+that we can expect from particular approaches? 
+3. Will it be possible to change the program when conditions change? 
+How much will it cost to make the change? 
+4. How efficient is the program, and what do we mean by efficiency? 
+Are we trading efficiency in one area for inefficiency in another? 
+In the future, and particularly in the discussion of this book, we should 
+refrain from using the concept “good program” or ‘‘good programmer’’ 
+as if it were something universally agreed upon, or something that even 
+can be universally agreed upon, or something that even should be uni- 
+versally agreed upon. 
+QUESTIONS 
+For Managers 
+1. On what bases do you reward programmers? Are certain 
+of your 
+criteria mutually contradictory, as in asking for efficient but general 
+programs? How explicit are you with your programmers in indicating 
+-what you are looking for in their programs? Or do you just tell them 
+that you want the programs to be fast, small, neat, easily modifiable, 
+errorless, and done in a week? 
+2. How do the programs in your installation stack up on adaptability? Is
+
+<!-- PDF page 54 -->
+26 
+Programming as Human Performance 
+modifying programs a major expense in your installation? 
+If so, can 
+you see things in your programming practices—in the original goals 
+you set—that may lead to this kind of expense? 
+3. How important is making the schedule in your shop? Is “a miss as 
+good as a mile,’”’ or do you reward for consistency rather than the 
+occasional lucky shot? Can you see how a programmer can choose 
+an unreliable practice because it gives him the only hope of making 
+the schedule, even though it may risk not finishing the program at all? 
+For Programmers 
+1. Do you have criteria explicitly in mind when you start on a project? 
+Are these criteria obtained from your own impression of what is im- 
+portant, or do you get them from your manager? Do your criteria 
+change as the project progresses, 
+or do you have some device for 
+keeping them firmly in mind? 
+2. 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? 
+3. Have you ever tried for ‘‘efficiency” at the expense of getting the job 
+done? For “meeting the deadline’’ at the expense of doing it right? 
+BIBLIOGRAPHY 
+Fisher, Ronald A., The Genetical Theory of Natural Selection, New York, Dover 
+Publications, 1958. 
+See particularly Chapter II for a discussion of the Fundamental Theorem of Na- 
+tural Selection. 
+Weinberg, G. M., PL// Programming, A Manual of Style, New York, McGraw-Hill, 
+1970. 
+See especially Chapter 4 on the question of the compromises among the various 
+criteria for ‘‘good”’ programs.
+
+<!-- PDF page 55 -->
+Silver Anniversary Notes (27 
+Comments on 
+Chapter 2: 
+What 
+Makes a 
+Good Program? 
+The biggest new factor in determining how we judge the quality of code is the 
+economic factor. 
+A program that sells, and makes profits, is obviously better 
+than one that doesn’t. At least several non-programmers have told me that Bill 
+Gates is the world’s greatest programmer. 
+In my career as a programmer, most 
+of the operating system code | wrote was given away, so naturally I’m suspicious 
+of this financial measure. 
+Bult, in all honesty, if the purpose of writing the pro- 
+gram is to make money, then the one whose program makes the most money is 
+certainly the best programmer—the best at realizing the requirements. 
+In the original chapter’s story of efficiency versus effectiveness, the card-read- 
+ing activity certainly dates the example, but the point is the same regardless of 
+what input medium is used. Over the years, I’ve arrived at a definition of quality 
+that generalizes this case: Quality is value to some person. To the programmers 
+of that era, speed was a more important measure of value than was confor- 
+mance to function. 
+Studying the psychology of value judgments explains why 
+software developers made the choices they did, puzzles that would otherwise 
+simply be ancient mysteries. 
+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. 
+Ten years ago, | would have been embarrassed by the sexist language used 
+so unconsciously in the seventies (“beautiful and modest wife,” and “him” and 
+“his” where “her” and “hers” would have done fine [p. 22]), because | had
+
+<!-- PDF page 56 -->
+PS 
+Silver Anniversary Notes 
+become well aware of the presumption of this usage and had worked hard to 
+root it out of my writing. Reading the original today, | simply find this change in 
+language an interesting measure of my growing up, and hopefully of society’s 
+growing up. Twenty-five years ago, few of us were aware of what assumptions 
+we were making with our sexist writing. 
+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. 
+It’s as if they think all you have to do to manage the New York Yankees is 
+tell every batter to hit a home run and every pitcher to strike the batter out. 
+The trade-off between computer time and human time has changed, as predict- 
+ed. “And so we expect that with each passing year we will hear less and less 
+about efficiency—and more and more about effectiveness” (p. 25). Nevertheless, 
+there are still jobs where efficiency is essential, just not all. We are learning this. 
+For the most part, I’m astonished at how well the Questions sections at the 
+end of the chapters stand up to the test of time—with some hilarious exceptions. 
+The same is true for the bibliographic references, though not the computer-spe- 
+cific ones. 
+It seems that there is some consistency to human behavior, if not to 
+human technology.

library/The Psychology of Computer Programming/Chapter-11-Programming-Languages/Chapter-11-source-text.md

@@ -0,0 +1,655 @@
+# The Psychology of Computer Programming — Chapter-11: Programming Languages
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 263–276
+- **Pages without text**: none
+- **Note**: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.
+
+---
+
+<!-- PDF page 263 -->
+PROGRAMMING 
+LANGUAGES 
+it 
+ountless papers have been devoted to the subject of program- 
+ming languages, but the topic of psychology is not easily found 
+in any of them. The most typical attitude about programming 
+languages was expressed by one author who pleaded 
+for an 
+effort “to really attempt to understand what programming and program- 
+ming languages are all about.” Although we all could agree with this 
+laudable sentiment, we might not agree with his explication of what he 
+thought they were “all about,’’ namely, ‘how they related to our mathe- 
+matical foundations on the one hand and to current as well as imagined 
+computing equipment on the other.” In that analysis, there is no mention 
+of people, the poor critters who have to use programming languages, 
+except perhaps for the type of people who spend their time imagining 
+computing equipment—hardly the typical language user! 
+In this chapter, we also shall attempt to understand what programming 
+languages are all about, but our point of view will consider people first 
+205
+
+<!-- PDF page 264 -->
+206 
+Programming Tools 
+and machines and mathematics second—and then only as they impinge 
+on the psychological discussion. As we have already, in this book, spent 
+considerable time discussing what “programming” 
+is, it will be appro- 
+priate to begin our study of programming languages by considering what 
+a “language” 
+is, and to what extent programming languages are lan- 
+guages in other senses of the term. With that understanding as a basis, 
+we will attempt to throw some small light on the subject of programming 
+language design. Since most programmers do not have much to say 
+about the design of a language, we shall attempt to satisfy a more uni- 
+versal need by providing principles for selection of a programming lan- 
+guage from among those already designed for us. 
+PROGRAMMING LANGUAGE AND 
+NATURAL LANGUAGES 
+lf there is one area in which every man is an expert, it is language. We 
+all speak a language, and some of us can even read and write the lan- 
+guage we speak. If a foreigner says “I would like of dinner,’’ any of us can 
+correct his erroneous use of the preposition—even those of us who do not 
+know a preposition from a proposition or a prepossession. The typical 
+person’s understanding of the language he uses, however, is not so pro- 
+found as to prevent him from labeling something as a language that might 
+resemble one only superficially. Thus, it is not surprising that the systems 
+of notation which we use to communicate with our computers came to 
+be known as “programming languages.” In fact, the very first programmer, 
+Lady Lovelace, seems to have had the idea of a programming language 
+as a language as early as 1846. Although she was the niece of Lord 
+Byron, it was not her knowledge of poetry but, rather, of mathematics 
+which led her to think of a symbolic system as a language—for the idea 
+of mathematics as a language seems to go back into the misty ages of 
+the past. Thus, the idea of “programming language” was really born 
+with the idea of programming itself. 
+In view of the venerable past of the programming language concept, it 
+would be pedantic to attempt to demonstrate that programming languages 
+are not “real” languages. Languages are what they say they are, and we 
+are perfectly entitled to include systems of communications between man 
+and computer under the same rubric as systems of communication be- 
+tween man and man or beast and beast. What might be possible, however, 
+is to inquire about possible differences between computer languages and 
+the other kinds. 
+One possible point of departure for comparing the two types of lan- 
+guage is the list of ‘design features’ which Hockett has given for the
+
+<!-- PDF page 265 -->
+Programming Languages 
+207 
+natural language of human beings (speech). The first of thirteen features 
+which he lists is the use of a “vocal-auditory channel’’—that is, | speak 
+and you listen. The use of this channel has several advantages, particu- 
+larly the freeing of the hands and other organs for separate activities. 
+Programming is generally a manual operation—we laugh when someone 
+asks us to “say something in FORTRAN.” It is a written language, and in 
+spite of its resemblance to other written languages, 
+it differs from them 
+in not having a speech system behind 
+it. Not that written languages are 
+simple transcriptions of speech, not at all; but a written language such as 
+English is strongly influenced by its relationship to a spoken language. 
+This influence is not so strong in other written languages, such as those 
+using the Chinese writing system, but the influence—the mutual influence 
+—always exists. 
+One effect of not having a spoken form of a programming language is 
+a possible slowing down of language innovations, for the spoken form 
+of the natural language is most often the source of new language forms. 
+Another effect is the difficulty with which we can talk about a program- 
+ming language without a blackboard or pencil and paper. Every program- 
+ming office should have a blackboard, chalk, and many erasers. 
+The second of Hockett’s features 
+is “rapid fading.” We need many 
+erasers because what we “say” about a program on the blackboard does 
+not erase itself the way an utterance does. Sometimes it is a convenience 
+to have rapid fading in a programming language. Once, when installing 
+a computer in Bermuda, we fell into the habit of sketching our rough 
+programming ideas in that portion of the coral sand between the apogee 
+and perigee of the wash of waves. The ocean saw to it that each idea 
+lasted only about as long as it was worth; but in ordinary programming 
+work, we usually have to make explicit provision for getting rid of our 
+obsolete listings, unless we have a graphic terminal. 
+The third feature is ‘‘broadcast transmission and directional reception,”’ 
+which means that we speak more or less in all directions at once, but we 
+can detect, when listening, from what direction the speech is coming. 
+Programming, of course, is quite the opposite. Programming shares with 
+prayer the feature of directional transmission and broadcast reception. 
+Heaven receives prayers, and the computer receives programs, from all 
+over at once. We might imagine, then, that what variation is permitted in 
+programming languages would be on the way out of the computer, but 
+just the opposite is true. 
+In spite of the diversity of its listeners, the 
+“system” simply broadcasts identical messages to all of them. Certain 
+possibilities for change lie here. 
+Probably the really important difference between 
+programming 
+lan- 
+guages (of today) and natural languages lies in Hockett’s fourth design 
+feature—interchangeability. Although we often listen to people whom we
+
+<!-- PDF page 266 -->
+208 
+Programming Tools 
+cannot understand, or often speak to people who cannot understand us, 
+the normal image of human speech communication is that each partici- 
+pant can reproduce any linguistic communication he can understand. In 
+short, we “talk the same language.’”’ When we talk to our computers, 
+unhappily, we are usually speaking in different tongues. Here, at least, 
+for all their other faults, the machine languages have the upper hand, 
+for at least a dump looks a little like the stuff we put into the blasted 
+machine. Not so—not nearly so—when what we put in was FORTRAN or 
+COBOL. How truly sad it is that just at the very moment when the com- 
+puter has something important to tell us, it starts speaking gibberish. 
+There is, fortunately, a trend today to try to introduce interchangeability 
+into the dialogue between man and machine through a programming 
+language, and this step is bound to have important psychological effects 
+on programming effectiveness, even though 
+it may decrease machine 
+“efficiency.” But there is another kind of noninterchangeability which is 
+perhaps even more severe and yet less subject to mechanical remedies. 
+Programs are used not only for man-machine communication, but for man- 
+man communication 
+as well. Yet communication 
+in programming 
+lan- 
+guages does not seem to have the interchangeability we take for granted 
+in natural language communication, even between the same two people. 
+At the extreme of this problem is the case of the man who can read 
+COBOL programs but cannot write them. Probably, he cannot discuss 
+them, either, which makes for most difficult communication problems 
+if 
+he is, say, a programming manager. 
+In Hockett’s 
+remaining design 
+features, programming 
+languages do 
+seem to measure up to natural languages—actually going beyond them 
+in the exhibition of such features as productivity, the ability to express 
+something that has never been expressed before. In a way, the design of 
+programming languages reflects different patterns of use than are com- 
+monly found in natural language. To be sure, it is important that a natural 
+language be productive, in the above sense, but for a programming lan- 
+guage, productivity is the sine qua non. 
+When we consider function of a language, rather than the design fea- 
+tures which realize function, the deepest differences between program- 
+ming languages and natural languages emerge. Bruner gives six general 
+functions 
+of natural language—emotive, 
+connotative, 
+referential, 
+meta- 
+lingual, poetic, and phatic. Although we can identify each of these in 
+programming languages, their relative importance and frequency of use 
+is quite different. 
+Emotive language consists of utterances such as “‘How do you do?” and 
+“Fiddlesticks!,” which are ritualized expressions of the emotional state 
+of the speaker. Generally speaking, the computer is not interested in the 
+emotional state of the programmer, although evidences of it may creep
+
+<!-- PDF page 267 -->
+Pregramming Languages 
+209 
+into his program. Phatic language consists of utterances such as “Uh 
+hu... but...and...,”’ which serve the function of keeping the channel 
+of communication open or testing its state of operation. An exact counter- 
+part of the phatic “and” is found in some terminal systems where the 
+user can keep his program from being pushed down in the priority stack 
+by fiddling with the shift key while he is thinking. Without the shifting, the 
+computer would fail to get a communication for a long period and assume 
+that the user’s program could safely be put in a more passive state. Of 
+course, jiggling the shift key defeats the purpose of the scheduling algo- 
+rithm, but more important than that is the interference it probably causes 
+with the programmer’s thought processes. Hopefully, such phatic com- 
+munication can be removed from the already cluttered field of program- 
+ming language phenomena. 
+At first blush, poetic language would seem to have no place in pro- 
+gramming, yet it plays a role which should be increasingly recognized. 
+In poetic language, the patterning of the language itself—for esthetic 
+reasons—is uppermost. But what, in programming, is there to correspond 
+to Keats’ lines such as these? 
+O Attic shape! Fair attitude! with brede 
+Of marble men and maidens overwrought, 
+With forest branches and the trodden weed; 
+Thou, silent form, dost tease us out of thought... 
+lf we mean to read aloud, the answer is nothing, for we have already 
+seen that programming language is not speech, let alone song. But is 
+there not, indeed, something in form for form’s sake which “dost tease us 
+out of thought’? 
+A programmer would not really be a programmer who did not at some 
+time consider his program as an esthetic object. This part is not quite 
+symmetrical; that part is clumsy and doesn’t flow in an appropriate man- 
+ner; the whole thing does not look proper on the page. To be sure, it is 
+fashionable among programmers to be rough and tough and pragmatic, 
+but deep down each programmer knows that it is not enough for a pro- 
+gram just to work—it has to be “right’’ in other ways. Later, when we 
+discuss language design and program testing, we shall see that the cor- 
+relation 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.”’ 
+The prose of programming consists largely of referential and connota- 
+tive parts. Referential statements are statements or questions of fact— 
+“That is Heidi,” “This is a fixed-point binary number with 13 bits and a 
+sign.” Connotative statements give instructions—‘‘Stop pulling my leg,”
+
+<!-- PDF page 268 -->
+210 
+Programming Tools 
+“Find the inverse of this matrix.’”’ Of these types, we shall say more later. 
+But here we should note that, although both are common in natural and 
+programming languages, the universe of discourse is much, much smaller 
+in programming. Thus, even though there is essentially no limit to the 
+number of assignment statements or declarations in PL/I, the number of 
+possible utterances in English is enormously greater. We are aware of 
+the importance of the size of the universe of discourse in programming 
+languages, but it is probably most important for their psychology, as we 
+hope to show. 
+Metalingual utterances—talking 
+about language—are 
+of primary im- 
+portance in programming, especially in the learning process, when pro- 
+gramming such things as compilers, and when designing and defining 
+programming languages. Until recently, programming languages differed 
+from natural languages in that they relied exclusively on natural language 
+as a metalanguage—with the possible use of a little mathematics. This 
+chapter, for example, is one long metalingual statement about program- 
+ming languages, completely couched in English. Now, however, increas- 
+ing attention is being turned to special formal or informal languages de- 
+signed to facilitate metalingual expression and reasoning. Moreover, cer- 
+tain programming languages are beginning 
+to incorporate metalingual 
+features 
+of great power—giving 
+us the ability not only to manipulate 
+programming languages but to manipulate assertions about programming 
+languages. Although the future of these efforts is not clear, and empirical 
+evidence 
+is almost entirely lacking, we hope to be able to give some 
+hints of the role which metalingual features can play in the psychology of 
+programming languages. 
+PROGRAMMING LANGUAGE DESIGN 
+It is impossible to begin a discussion of psychological principles of 
+programming language design without recalling the story of “Levine the 
+Genius Tailor.”” 
+It seems that 
+a man had gone to Levine to have a suit 
+made cheaply, but when the suit was finished and he went to try it on, it 
+didn’t fit him at all. ‘“‘Look,” he said, ‘‘the jacket is much too big in back.” 
+“No problem,” 
+replied Levine, showing him how to hunch over his 
+back to take up the slack in the jacket. 
+“But then what about the right arm? It’s three inches too long.”’ 
+“No problem,” Levine repeated, demonstrating how, by leaning to one 
+side and stretching out his right arm, the sleeve could be made to fit. 
+“And what about these pants? The left leg is too short.” 
+“No problem,” said Levine for the third time, and proceeded to teach
+
+<!-- PDF page 269 -->
+Programming Languages 
+211 
+him how to pull up his leg at the hip so that, though he limped badly, the 
+suit appeared to fit. 
+Having no more complaints, the man set off hobbling down the street, 
+feeling slightly duped by Levine. Before he went two blocks, he was 
+stopped by a stranger who said, ‘| beg your pardon, but is that a new 
+suit you’re wearing?” 
+The man was a little pleased that someone had noticed his suit, so 
+he took no offense. “Yes it is,” he replied. “Why do you ask?” 
+“Well, I'm in the market for a new suit myself. Who’s your tailor?” 
+“It's Levine—right down the street.” 
+“Well, thanks very much,” said the stranger, hurrying off. ‘I do believe 
+’ll go to Levine for my suit. Why, he must be a genius to fit a cripple like 
+you!” 
+Would 
+it be inappropriate to concoct a version of this story called 
+“Levine the Genius Language Designer’? The first problem in discussing 
+language design is that we do not know the answer to that question. We 
+do not know whether the language designers are geniuses, or we or- 
+dinary programmers are cripples. 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. 
+Why are our standards so flexible in this matter when they are all too 
+often rigid in others? The problem lies in the rigidity of our machines 
+and, through them, in the rigidity of our programming languages. When- 
+ever a man is confronted with a new machine, he is forced to choose be- 
+tween making some adjustments himself or adjusting the machine to 
+narrow the gap between what is desired and what exists. Although ma- 
+chines, 
+and especially computers, 
+are adjustable, the time scale for 
+them to be changed is generally much longer than for a person. Pro- 
+gramming languages are attempts to adjust the raw computer to better 
+fit human propensities and limitations, but they too suffer from a long 
+update cycle. Thus, the user 
+is faced with the choice of waiting for 
+months or years while he develops his own programming language—a 
+primrose path which many a man has trod—or gritting his teeth and 
+learning to live with what he has. 
+Humanists often contend 
+that machines tend to dehumanize people 
+by forcing them to have rigid personalities, but really, the contrary is 
+true. Because the machines are rigid, the people who use them must— 
+if they are to be successful—supply more than their share of flexibility. 
+Perhaps this is the effect that the humanists are describing as ‘““dehuman- 
+ization,” for in ordinary human intercourse, each party gives and takes
+
+<!-- PDF page 270 -->
+212 
+Programming Tools 
+his share. Relationships in which one party does all the giving or all the 
+taking are not fully human, and tend to produce personality distortions 
+in one or the other. 
+In making our adjustments to our particular programming language, 
+we can easily become attached to it simply because we now have so 
+much invested 
+in it. We often listen to a man complaining about his 
+nagging, slovenly, and prodigal wife, only to find that when asked why he 
+doesn’t leave her, he replies that he cannot live without her. Most people 
+would prefer almost any amount of pain to giving up the familiarity of 
+some constant companion for an unknown quantity. We see this effect 
+when we try to teach a programmer his second language. Teaching the 
+first is no great problem, for he has no investment in any other. By the 
+time he has learned two or more, he is aware that more things exist in 
+this world than he has dreamed of. But letting go of the first is, to him, 
+just a promise of pain with no promise of compensating pleasure. 
+Perhaps this situation could be improved 
+if we could enunciate and 
+teach certain 
+principles that are not tied to particular languages, so 
+that even the beginner would have some less relative measure to hold up 
+against the language he is learning. But teaching practice today in our 
+universities and programming schools seems to be pointing in exactly 
+the opposite direction. Instead of trying to teach principles, or at least 
+trying to teach two contrasting programming languages simultaneously, 
+or at the very least trying to teach one programming language which 
+rather broadly represents the major possibilities, the schools seem de- 
+voted to teaching how to program in a single simple and artificial lan- 
+guage. The objective seems to be to get the student writing some kind 
+of program as soon as possible—a not unworthy aim—but at the expense 
+of limiting the future growth of the programmer. 
+To be fair, we should recall our distinction between the professional 
+and amateur. The schools, it seems, are devoting themselves primarily to 
+turning out vast quantities of amateurs—perhaps under the assumption 
+that the professionals can and should take care of themselves. But when 
+the language designers begin to believe that the principles underlying 
+the design of an amateur’s language are the same as those upon which 
+a professional’s are based, then we have trouble. 
+In order to get at the principles underlying the design of programming 
+languages to fit psychological 
+realities, we shall have to get down to 
+fundamental empirical data. Reading programs will be a help, but reading 
+is not enough. When we read a program, we can seldom tell with cer- 
+tainty why a particular piece of coding is present. To understand the 
+psychology of programming languages, we shall have to do more than 
+read programs—we shall have to observe programs being made. Even
+
+<!-- PDF page 271 -->
+Programming Languages 
+213 
+this process—even 
+interviewing programmers—will 
+not tell us 
+all we 
+want to know, and we shall have to resort to many sources and devices 
+to get even a slightly better picture than we have by intuition. One reason 
+for these complexities 
+is that the programmer himself seldom knows 
+why he does what he does—which is a general problem in the study of 
+any human behavior. 
+Consider, for example, the following situation. A programmer writing 
+in FORTRAN wants to use a subscript expression such as (J-21). He knows 
+that there are rules—perfectly explicit and unambiguous—about which 
+subscript expressions are permitted and which are not. But he is not 
+quite sure of the rule as it applies to this case, so what does he do? 
+Well, he might look up the rule in his manual, but if he is a clever fellow, 
+he will probably just make a preliminary calculation by such a statement 
+as 
+K — J-21 
+He is sure that K is an acceptable subscript, and this is much faster 
+than looking up the rule. It may—to be sure—be slower in the program, 
+but that is not the question uppermost in his mind at this moment.. 
+Now, why did the programmer do this? Because of a limitation in the 
+FORTRAN language? But, you might argue, J-21 
+is not prohibited by 
+FORTRAN, so it must be a limitation of the programmer—of his under- 
+standing of FORTRAN. Although this argument places the blame, it mis- 
+leads us in designing or evaluating a programming language, for would 
+it not be also correct to say that in PL/I, the programmer would have 
+been much less likely to make this error? Why? Because he would be 
+more 
+likely to know that there were 
+no restrictions on subscripts 
+in 
+PL/I, so it would not even occur to him to worry about whether a par- 
+ticular expression was permitted or not. 
+When we assess a programming language, or a machine, from a psy- 
+chological point of view, we cannot grant ourselves the luxury of putting 
+all the burden of poor programming on the poor programmer. If the same 
+programmers 
+get consistently 
+better 
+results 
+using 
+language 
+A than 
+using language B, what good are arguments that they would have done 
+better in language B, if only they had been smart enough to master it. 
+Of course, there is a time dimension to this argument, for one must 
+learn to use a programming language or a machine. Thus, the evaluation 
+of these things depends on the entire system comprising the courses, 
+teaching 
+materials, 
+language, compiler 
+hints, programming 
+assistance 
+and anything else, which may lead to one language being better used 
+than another. Perhaps the messages coming from the terminal when an 
+error is made are more motivating in one system than another. Perhaps 
+the programmer feels he is more important if he is chosen to program
+
+<!-- PDF page 272 -->
+214 
+Programming Tools 
+in machine language instead of FORTRAN. 
+If we are to be effective in 
+improving the quality of languages, we shall not be able to dismiss any 
+such factor out of hand. 
+In a way, the reason it is so hard to attribute the source of program- 
+ming inefficiency 
+to either programmer 
+or programming 
+language 
+is 
+that if we had ideal programmers, programming languages would not be 
+necessary. It is a psychological difficulty which prevents us from writing 
+our problem specifications directly in machine language. Let’s face up 
+to it: people don’t think the same way that computers do—that’s why 
+we use computers. Programming 
+is at best a communication between 
+two alien species, and programming languages with all their systems 
+paraphernalia are an attempt to make the communication simpler for one 
+of those species. Which one? Not the computer, certainly, for nobody 
+ever heard a complaint from a computer that it couldn’t do the work. 
+SUMMARY 
+The use of the term “language” in the phrase “programming language”’ 
+is in many ways damaging to progress in communication between man 
+and machine. Just calling it a language doesn’t make it one, and may 
+instead lead to false analogies which, in turn, lead to misguided research 
+efforts. To make progress in programming languages, we must first give 
+up the holy grail of trying to program in a “real” language, for program- 
+ming languages can never be the same as human speech. We may then 
+transfer our quest to making programming languages more ‘‘natural,’’ not 
+in the sense of being identical to English or some other culture’s con- 
+tribution to the Tower of Babel, but in the sense of a consonance be- 
+tween the mode of expression and the mind of the expressor. But in the 
+end, to get a good ‘“‘fit,”” perhaps the customer will have to scrunch over 
+a little—perhaps we are ultimately going to have to change our ways of 
+thinking to fit our computers. Why not? Hasn’t every other human in- 
+vention changed man? 
+QUESTIONS 
+For Managers 
+1. Are chalkboards standard equipment 
+in your programming offices? 
+Have you ever turned down a request for a chalkboard? 
+2. How were the programming languages used in your shop chosen? 
+3. Relate any experiences you have had with a change in programming 
+languages in your shop.
+
+<!-- PDF page 273 -->
+Programming Languages 
+215 
+For Programmers 
+1. Is the person who designed your language a genius? Give some ex- 
+amples of his genius, from your own experience. 
+2. Relate your experiences in learning your first and second and third 
+programming languages, trying to point out psychological differences 
+in the experiences based not so much on the languages themselves 
+but on the order you learned them. 
+3. If you are an experienced FORTRAN programmer, can you give the 
+precise rules for subscript expressions? Are you sure? How does it 
+influence your programming when you are not sure of a rule? Do you 
+look it up? 
+4. Has being a programmer changed the way you think when you are 
+not programming? If so, give some examples. 
+BIBLIOGRAPHY 
+Morrison, Phillip, and Emily, eds., Charles Babbage and His Calculating Engines, 
+New York, Dover Publications, 1961. 
+Along with Babbage’s writings on his machines, we find Lady Lovelace’s com- 
+ments, which show a clear understanding of many of the fundamental principles 
+of programming languages. Those who believe that the progress of knowledge is 
+monotonic and increasing should read this book carefully. What happened, they 
+should ask, to this understanding between the years 1860 and 1940? Perhaps 
+because Babbage was unable to separate clearly the principles of his machine 
+from their mechanical embodiment, his works lay scattered and forgotten 
+in li- 
+braries all over the world, only to be rediscovered after his inventions had been 
+reinvented in an electric and electronic embodiment. Is there a lesson here, too, 
+about programming languages? 
+Zemanek, 
+H., Semiotics and Programming 
+Languages, Communications 
+of the 
+ACM, 9, No. 3 (March 1966), pp. 139-43. 
+Zemanek was the head of the IBM Vienna Laboratory while it was developing the 
+Universal Language Document 
+for PL/I, probably the most ambitious metapro- 
+gramming document 
+ever attempted—and 
+probably the most successful. 
+This 
+article gives some of the structure of his thought, which clearly influenced the 
+course of the ULD development. 
+Greenberg, Joseph H., Universals of Language, 2nd ed., Cambridge, Mass., M.I.T. 
+Press, 1966. 
+Based on, but not a verbatim account of, a 1961 conference, this book gives a 
+good introduction to the search for universal features of languages. In addition to 
+Hockett’s paper, it contains at least six other papers that should be of interest to 
+programming 
+language designers, although, 
+of course, programming languages 
+are not considered languages by these linguists. 
+Bruner, Jerome, Toward a Theory of Instruction, Cambridge, Mass., Belknap Press 
+of Harvard University, 1966. 
+Bruner gives his six general functions of language, along with many other thoughts.
+
+<!-- PDF page 274 -->
+216 
+Programming Tools 
+Bruner is one of the most important modern thinkers and researchers in the areas 
+of language, learning, and thought, and this book is a good introduction to his 
+ideas. 
+Miller, George A., Language and Communication, revised ed., New York, McGraw- 
+Hill, 1963. 
+No programming language designer should be permitted to design another lan- 
+guage until he has read this book. As Miller says in his introduction: “A scientific 
+study of language, as opposed to a speculative discussion, begins with direct 
+observations of communicating individuals and searches for the relation of these 
+observations to the existing body of scientific knowledge.” 
+Vygotsky, Lev Semenovich, Thought and Language, Cambridge, Mass., M.!.T. Press, 
+1962. 
+The translation of the work by the great but short-lived Russian psychologist re- 
+mains today probably the most stimulating and readable work on the relationship 
+between thought and language. No programmer could fail to profit from reading 
+this book. 
+Steel, T. B., Jr., ed., Formal Language Description Languages for Computer Pro- 
+gramming, Amsterdam, North-Holland Publishing Co., 1966. 
+These papers are the proceedings of an IFIP working conference on formal lan- 
+guage description languages—that is, on formal metalanguages for programming 
+languages. Although uneven, it is a rich mine of conceptual nuggets for those in- 
+terested in the language of language, or the language of language of language, 
+Orierrs 
+Symposium on Extendible Languages, Sigplan Notices, 4, No. 8, Association for 
+Computing Machinery, New York, 1969. 
+Extendible, 
+or extensible, programming languages are languages 
+in which the 
+language itself can be manipulated by the programmer, This symposium 
+fairly 
+well represents the state-of-the-art at the time it was published. 
+Sammett, J. E., The Use of English as a Programming Language, Communications 
+of the ACM, 9, 3 (March 1966), pp. 228-30. 
+Higman, Bryan, 
+A Comparative Study of Programming Languages, Section 15.3: 
+Subsets of English, New York, American Elsevier, 1967. 
+Two essays to discourage those who think that the answer to all our problems 
+is to program in a “real” language.
+
+<!-- PDF page 275 -->
+Silver Anniversary Notes 
+x, 
+Pi 
+Comments on 
+Chapter 11: 
+Programming Languages 
+Over the years, programming languages have in some ways become more 
+“natural,” yet, at the same time, we finally seem to have given up the rather 
+ridiculous idea of programming in “natural language.” 
+The change has been 
+two-way, as many terms and concepts from programming have crept into use in 
+our natural language. 
+For example, even as dumps have become rare in soft- 
+ware development, the term “memory dump” has become a way of describing a 
+boring monologue. 
+We've all learned things in twenty-five years, but we may not have noticed 
+learning most of them. When | reread my words on the lack of a “vocal-auditory” 
+channel for programming languages (p. 207), | realized that at the time | wrote 
+the section | had never worked with blind programmers—people who use the 
+vocal-auditory programming language all the time. 
+Alas, at the same time the 
+vocal-auditory channel is improving for blind programmers, programming lan- 
+guages are taking a turn for the visual—which enormously complicates the blind 
+programmer’s life. The details change, but the principle remains the same: 
+What is a good language for one person is anathema for another. 
+Object-oriented (OO) languages provide a case in point. Although many OO 
+enthusiasts don’t realize it, the first OO language existed more than twenty-five 
+years ago. Of course, you wouldn’t know it from the first edition of Psychology, 
+because | didn’t include material on the subject. Back then, | didn’t think the OO 
+ideas would ever be important for general-purpose programming. 
+| had worked
+
+<!-- PDF page 276 -->
+Silver Anniversary Notes 
+with Simula’s creators in Oslo in 1968 and was a Simula enthusiast myself, but | 
+saw the language’s features through the eyes of a simulation developer, not a 
+language developer. 
+At the time, | failed to realize Simula’s potential—partly because | noticed how 
+few of my students seemed able to master the new way of thinking. Even today, 
+many programmers just don’t grasp the object-oriented paradigm, although this 
+situation may change as better teachers than | take over. 
+Even though technology has changed, some things haven’t changed at all. 
+Though whiteboards have replaced chalkboards, they serve the same essential 
+function (and still aren’t erased frequently enough). 
+Though the penance for 
+syntactic “sin” (syn?) is less severe in these days of personal computers, pro- 
+grammers still pray to their machines. Though the level of languages has gener- 
+ally been raised a notch or two, we still have to resort to hex gibberish when 
+things really start to go wrong. 
+And, to take a final example, “Levine the Genius Tailor’ (or “Genius Language 
+Designer’) remains a favorite story among my readers. 
+We still don’t know 
+“whether the language designers are geniuses, or we ordinary programmers are 
+cripples” (p. 211).

library/The Psychology of Computer Programming/Interlude-Part-1-Programming-as-Human-Performance/Interlude-source-text.md

@@ -0,0 +1,177 @@
+# The Psychology of Computer Programming — Interlude: Part 1: Programming as Human Performance
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 26–30
+- **Pages without text**: 27
+- **OCR note**: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
+- **Note**: Part introduction and Silver Anniversary comments on the part.
+
+---
+
+<!-- PDF page 26 -->
+PROGRAMMING 
+AS HUMAN 
+_ 
+ERFORMANCE
+
+<!-- PDF page 27 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+The important thing is not to stop questioning.
+Curiosity has its own reason for existing. One can-
+not help but be in awe when he contemplates the
+mysteries of eternity, of life, of the marvelous struc-
+ture of reality. It is enough if one tries to compre-
+hend a little of this mystery every day. Never lose
+a holy curiosity.
+AlbertEinstein*
+omputer programming is a human activity. One could hardly dis-
+pute this assertion, and yet, perhaps because of the emphasis
+placed on the machine aspects of programming, many people
+-many programmers-have never considered programming in
+this light. Among programmers, there is a certain mystique--a certain
+waving of the hands which takes place whenever one tries to probe the
+manner in which programming is done. Programming is not done in a
+certain way, they say, it is just done. Either you can program or you
+cannot. Some have it; some don't.
+One of the corollaries of this mystique is the high salaries that must
+be paid. to those programmers who *have it"---and even to some who
+* From Death of a Genius, by William Miller, LIFE Magazine, May 2, 1955 C 1955 Time Inc.
+
+<!-- PDF page 28 -->
+4 
+Programming as Human Performance 
+don’t, just on the chance that they might. Perhaps because of these 
+high salaries, or because they cannot tolerate being at the mercy of a 
+mystique they don’t understand, 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. 
+Over the years, executives have backed their desire to eliminate pro- 
+grammers with staggering funds. Dozens of simplistic schemes have been 
+heaped with money and praise on the promise—as yet not kept—of 
+going directly from a sales proposal to a working data-processing system. 
+But we should not chide these executives for their naiveté in assessing 
+technical 
+merits. We should applaud them for their sophistication 
+in 
+sensing the source of so many of our problems. Their touching faith 
+in the magic of technology should serve as inspiration to those of us 
+who daily bend our backs to the programmer’s burden. Perhaps their 
+wishes—though they can surely never be fulfilled—should give us pause— 
+make us lift our noses from the coding pad or the terminal—and con- 
+sider this human activity of ours from a human point of view.
+
+<!-- PDF page 29 -->
+Silver Anniversary Notes 
+P1.i 
+Comments on 
+Part 1: 
+Programming as 
+Human Performance 
+Over the years, executives have backed their desire to elimi- 
+nate programmers with staggering funds. (p. 4) 
+The only thing that’s changed here in twenty-five years is the fact that the 
+funds dedicated by executives to eliminating programmers from their payrolls 
+have become far more staggering than | imagined back then. And, now, | finally 
+recognize in this executive desire a pattern so strong, so emotional, that it has 
+blinded these executives to two facts: 
+1. 
+None of these schemes has succeeded in eliminating programmers. 
+(We have now at least ten times as many as we did then.) 
+2. 
+Every one of these schemes has been concocted by programmers 
+themselves, the very people the executives want so passionately to 
+eliminate. 
+So, although people say that programmers lack interpersonal skills, they evi- 
+dently have a skill at persuasion that surpasses that of the late, great P.T. 
+Barnum, famous for proving his theory: “There’s a sucker born every minute.”
+
+<!-- PDF page 30 -->
+ow yh 
+Ai 
+i Hall | 
+iy We 04 
+YY ¥ nN 
+: 
+ea: 
+et 
+| 
+h 
+i 
+Bat 
+a, he) one 
+a Me 
+ia 
+Hin 
+’ 
+7 
+ie mt ov 
+al, sa 
+ie 
+" : 
+aes 
+‘high etter, ae Yo 
+mt 
+Meats 
+re 
+sO | Wang chip re 
+" miter 
+guna 
+Acie 
+Ty edie ei ghunt o Pia 
+pla 
+pie) 
+‘one vipat Un we ao » Pe: ree 
+tif Mitineiry Saath nit Ry 
+P viet ote Aas era a 
+. ev ee a | 
+LUNES 
+iy 
+Tr 
+Oe: i ka AP J srogeam rael Ss ~~ 
+#*, re 
+werner 
+5 ie ig 
+arp pu! Bay fu Ming mtn g v9 ASG 
+iL 
+: 
+fh 
+G00 
+Wow ener el ieee tg PAS At Mon Maite “SOA Ogi 
+. 
+5 
+ay 
+(‘hee 
+errnihy. Ot aie dork Peer) cee Wer 
+see’. at 
+7 ar ot 
+itp) m 
+“in Ol) aaa Het teat ANAT eon haan way en) wy ae / 
+a, ee environ cyali AWN BEMIS NG sate a 
+r 
+ert) faith ton? writ €) eiaey ere rat svar beignevis ict ghirt one ut 
+seni ont ant ated BUG Qnvsnniis of eavihnane Ya treater rita 
+vitesse | wien eA nel: Aged Ger we ‘Tnant pohagoeta oon tai bane: 
+det 8 tant 
+Jenohome of .pnonte of THelig's Hideb sviRUIKS ot OH 4 
+La) 
+3 
+et anal ew qpomiianers pert 
+Pini) ON atilaeieitie nm bet waseue iad asiade ante Ny @nol 
+4 hert 
+bi ear as yeas damitnal femal Is wor evet! aW)” 
+srammengeig Yl Betgerco Caet ert eamersa pao 
+10 eno’ sei 
+of VAasisrclenetie) de" traw aewiluaexs eet: saa bsnid “tt Yacianalanene 
+» 
+in wy 
+; 
+Ju 
+af 
+p une) 
+| We 
+nine ate 
+wlaaty Yo taitt sooesqnue 
+tart! mot 
+ee sat saesain 6 Perey” 
+0

library/The Psychology of Computer Programming/Interlude-Part-2-Programming-as-a-Social-Activity/Interlude-source-text.md

@@ -0,0 +1,152 @@
+# The Psychology of Computer Programming — Interlude: Part 2: Programming as a Social Activity
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 77–82
+- **Pages without text**: 77
+- **OCR note**: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
+- **Note**: Part introduction and Silver Anniversary comments on the part.
+
+---
+
+<!-- PDF page 77 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+[Image-only page; OCR found no readable text. Consult the PDF for visual content.]
+
+<!-- PDF page 78 -->
+2 
+a 
+: 
+DROGRN MING 
+ch 
+OCA. 
+ACINIV
+
+<!-- PDF page 79 -->
+Having been brought up in a serf-owner’s family, 
+! entered active life, like all young men of my time, 
+with a great deal of confidence in the necessity of 
+commanding, ordering, scolding, punishing, and the 
+like. But when, at an early stage, | had to manage 
+_ serious enterprises and to deal with men, and when 
+each mistake would lead at once to heavy conse- 
+quences, | began to appreciate the difference be- 
+tween acting on the principle of command and disci- 
+pline 
+and 
+acting 
+on 
+the 
+principle 
+of common 
+understanding. The former works admirably 
+in a 
+military parade, but it is worth nothing where real 
+life is concerned, and the aim can be achieved only 
+through the severe effort of many converging wills. 
+Peter Kropotkin* 
+rogrammers do not ordinarily work in isolation. Although an in- 
+dividual programmer may find himself assigned the task of writing 
+@ program, even then he has other programmers to whom he may 
+turn for help—and who, at the same Hed may be turning to him. 
+* Reprinted from Memoirs of a Revolutionist, by Peter Kropotkin. Copyright — a per- 
+_ mission of the Publisher, Horizon Press, New York. 
+45
+
+<!-- PDF page 80 -->
+46 
+Programming as a Social Activity 
+Indeed, as we shall see, the programmer working alone is working under 
+a serious handicap. But when working with others, many types of relation- 
+ships can exist. For our purpose, we shall identify three sorts of pro- 
+grammer assemblage—the group, the team, and the project. Roughly 
+speaking, the group is a collection of programmers, working in the same 
+place, probably sharing the same machine and system, but working on 
+separate programs, although there may be a relationship among some 
+of the programs. A typical programming group might be found 
+in a 
+university computing center, an engineering firm, or wherever an “open 
+shop” is run. 
+A programming team, on the other hand, is a collection of programmers 
+who are trying to produce a single program by working together. A team 
+might consist of from two to twelve members, though with the larger 
+numbers the team begins to break down into two or more teams. The 
+team may exist within a programming group or perhaps be one team of 
+many. making up a programming project. The project is a group of pro- 
+grammers 
+plus their supporting 
+activities 
+which 
+has probably been 
+brought together for the purpose of producing a single integrated system, 
+or at least a closely knit collection of programs. 
+It will often have its 
+own machine, plus special teams to provide systems work, standards, 
+documentation, and other functions. It will also ordinarily have a project 
+manager 
+and 
+a regular bureaucratic 
+organization—like 
+the Austrian 
+army.
+
+<!-- PDF page 81 -->
+Silver Anniversary Notes (R27 
+Comments on 
+Pah 2 
+Programming as a 
+Social Activity 
+[There are] three sorts of programmer assemblage—the 
+group, the team, and the project. Roughly speaking, the group 
+is a collection of programmers, working in the same place, 
+probably sharing the same machine and system, but working 
+on separate programs, although there may be a relationship 
+among some of the programs. ...A programming team, on 
+the other hand, is a collection of programmers who are trying 
+to produce a single program by working together. (p. 46) 
+After observing groups of programmers for another quarter-century, | have 
+changed my own definition of team. Now, | would say, “A programming team is 
+a collection of programmers who are trying to produce better products by work- 
+ing together.” 
+In other words, the distinguishing characteristic of the team is the way its 
+members produce products by working together—products that they could not 
+produce (or produce so efficiently) by working as individuals. Some teams share 
+a common product, while some groups working on a common product are not 
+teams. Some teams have each member working on a distinct product (although 
+this is less usual), while many groups share little except common space or a 
+common manager. 
+Now that hardware has grown cheaper while labor has
+
+<!-- PDF page 82 -->
+«Silver Anniversary Notes 
+grown more expensive, group members are much less likely to share a machine 
+and system than they were years ago. 
+In the end, though, it’s their method of /earning that distinguishes teams from 
+groups. 
+Because a common goal often influences group members to learn 
+together, it’s easy to see today why | was confused about this distinction twenty- 
+five years ago. 
+But with lots more examples under my belt, | now understand 
+that a common product goal need not lead to mutual learning. 
+On the other 
+hand, team members always have a common goal, regardless of the product— 
+the goal of helping each other learn to perform better. 
+My annual Software Engineering Management Development groups are 
+teams constructed with precisely this goal. Brian Pioreck, 
+a member of the 1998 
+team, commented on this goal: 
+“So, then, can this criterion be used to help organizations that want to build 
+teams that produce products instead of groups that produce products? And 
+learn what? 
+Learn how to build better programs? 
+Learn how to listen better? 
+communicate better? feel better about themselves? 
+| think the answer to all 
+these questions is yes. 
+“When | ask clients about their best experiences of being part of a team, the 
+most often cited memory is that it was like a family—a family around 
+Thanksgiving time. 
+Everybody makes something and brings it to the table, 
+where they can all share and celebrate. 
+| think another attribute of a healthy 
+team is that it can perpetuate itself. It can help a member break off and start and 
+support a new team that will share the same values and customs.”

library/The Psychology of Computer Programming/Interlude-Part-3-Programming-as-an-Individual-Activity/Interlude-source-text.md

@@ -0,0 +1,136 @@
+# The Psychology of Computer Programming — Interlude: Part 3: Programming as an Individual Activity
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 163–168
+- **Pages without text**: 165
+- **OCR note**: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
+- **Note**: Part introduction and Silver Anniversary comments on the part.
+
+---
+
+<!-- PDF page 163 -->
+’ "i, Are Mog 
+= 
+‘ 
+iw 
+vaie 
+4 
+‘ 
+Y iar 
+a
+
+<!-- PDF page 164 -->
+vw 
+a 
+DROGRAYING 
+As AN 
+NDNDUAL 
+ACINTY
+
+<!-- PDF page 165 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+I have in mind the only liberty worthy of that
+name, liberty consisting in the full development of
+all the material, intellectual, and moral powers latent
+in every man; a liberty which does not recognize
+any other restrictions but those which are traced
+by the laws of our own nature, which, properly
+speaking, is tantamount to saying that there is no
+restriction at all..
+Mikhail Bakunin*
+t the beginning of this book,'we set out to account for some
+programmers. We have seen that much of that variance can
+be accounted for by social factors-much more than we might
+have believed from casual considerations. But, no matter how much
+variance is attributable to social factors, there will always remain
+a residue. No matter how similar the structure of two programming groups
+might be, they will produce different finished products. In this section,
+we shall try to account for some of those differences by examining factors
+centering in and around the individual.
+*Reprinted with the permission of Macmillan Company. From The Political Philosophy ot
+Bakunin, by M. A. Bakunin. Copyright 1953, 1964 by the Free Press.
+119
+
+<!-- PDF page 166 -->
+120 
+Programming as an Individual Activity 
+How shall we proceed? Although little psychological research has been 
+done directly on programmers doing programming, we could imagine 
+that a psychological study had been done and think about how we would 
+analyze it to account for differences in performance by different subjects. 
+The first thing an experimental psychologist would ask is “Did all sub- 
+jects do the same task?” Even in a carefully controlled experiment, there 
+are many differences that might creep into what the subjects were doing, 
+or thought they were doing. Moreover, if we want to compare two different 
+experiments, we are obliged to look first for any difference in task before 
+we can draw meaningful conclusions. Certainly in programming, where 
+every task is different from every other in a multitude of ways, our first 
+invéstigations would have to be into task differences. 
+The next thing a psychologist would consider would depend on the 
+object of his experiment. If he were trying to measure individual differ- 
+ences, he would concentrate on keeping all aspects of the environment 
+as constant as possible so that they could be excluded from considera- 
+tion. He would not, for example, give a test to some subjects in an air- 
+conditioned room and others in a room that was overheated, for the room 
+temperature could easily be a more dominant influence on performance 
+than the individual differences he was trying to measure. 
+But if the psychologist were trying to measure the effect of temperature 
+on performance, he would make exactly this kind of variation. Instead of 
+holding the environmental variables constant, he would try to hold in- 
+dividual differences down to a minimum. To do this, he might try giving 
+the same test many times to the same individuals—although he would 
+then have to contend with learning effects, something we, too, must 
+consider. 
+In any case, we are interested in both the effects of environment and the 
+differences among individuals, so the order in which we consider them is 
+not really important—as long as we give both their due. 
+In the following chapters, we have broken down the factors which, in 
+sum, constitute what psychologists call “individual variations.’’ That is, if 
+two people are given the identical task to perform in the identical en- 
+vironment (which is, we all realize, an impossibility; yet it is a necessary 
+conceptual fiction), the differences in the way they behave can be attrib- 
+uted to one or more of these factors. The individual variations that inter- 
+est us may be further subdivided into the general categories of ‘‘person- 
+ality,” “intelligence,” and “training” or “experience.”
+
+<!-- PDF page 167 -->
+Silver Anniversary Notes 
+-xX 
+i 
+Comments on 
+Part 3: 
+Programming as an 
+Individual Activity 
+For me, the concepts in this part of the original book held the most hope—so 
+perhaps it was inevitable that it delivered the most disappointment. My goal was 
+to stimulate the study of how programmers do their work, and that’s not what I’m 
+disappointed about. 
+No, the past twenty-five years have seen a proliferation of 
+interesting experiments, such as those conducted in Ben Shneiderman’s labora- 
+tory at the University of Maryland. 
+My problem, like so many projects’ problems, arose from starting with the 
+wrong goal. My goal wasn’t really to stimulate a lot of experiments, but to stimu- 
+late the understanding that would lead to better results at the individual program- 
+mer’s level. 
+For the most part, that simply hasn’t happened. A quarter-century 
+later, individual programmers aren’t any more adept than were their predeces- 
+sors. They are not better suited to programming by personality, nor more intelli- 
+gent, nor better motivated, nor better trained, nor more experienced. They are, 
+however, far more productive. 
+Of course, | may just be an old geezer with a distorted view of how clever we 
+were when we were young geezers. 
+However, | don’t think so (of course!) for 
+two reasons. 
+First, we weren't smarter than the present-day programmers. 
+| 
+work with programmers almost every day, and they seem to be pretty much like | 
+was when | was young—very smart and highly motivated. At times, they seem 
+awfully, awfully clever; at other times, incredibly dense. 
+Ah, yes, | was exactly 
+the same, twenty-five years ago.
+
+<!-- PDF page 168 -->
+Silver Anniversary Notes 
+Second, | do think | can account for the differences in productivity in other 
+ways—better tools, better teamwork, better management, and better under- 
+standing of what tasks programmers are trying to accomplish.

library/The Psychology of Computer Programming/Interlude-Part-4-Programming-Tools/Interlude-source-text.md

@@ -0,0 +1,207 @@
+# The Psychology of Computer Programming — Interlude: Part 4: Programming Tools
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 257–262
+- **Pages without text**: 258, 259
+- **OCR note**: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
+- **Note**: Part introduction and Silver Anniversary comments on the part.
+
+---
+
+<!-- PDF page 257 -->
+Ka 
+a 
+Fa 
+“Py 
+ine 
+Be 
+ae a4 
++ ves 
+siya 
+‘ a 
+a ae 
+pie 
+ae 
+I, 
+gas 
+Pn to, re 
+cy 
++ 
+* 
+sd 
+ee 
+i 
+BAe 
+ae 
+: 
+an 
+wit 
+iy 
+. 
+« 
+his 
++ 
+AR 
+A 
+Mie 
+ee 
+: NY 
+Lae ok 
+i 
+u 
+b 
+Lien 
+" 
+4 
+j i MU od 
+ah 
+oe 
+; 
+.7 rN we 
+\: an . Ms
+
+<!-- PDF page 258 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+PART
+TOOLS
+
+<!-- PDF page 259 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+a word of advice to such of my hearers as
+may happen to be professors.I am allowed to use
+plain English because everybody knows that !
+coulid use mathematical logic if I chose. Take the
+statement: "Some people marry their deceased
+wives' sisters." 1 can express this in language
+which only becomes intelligible after years of
+study, and this gives me freedom. I suggest to
+young professors that their first work should be
+written in a jargon only to be understood by the
+erudite few. With that behind them, they can ever
+after say what they have to say in a language
+"understanded by the people." In these days, when
+our very lives are at the mercy of professors,I
+cannot but think that they would deserve our grati-
+tude if they adopted my advice.
+BertrandRussell*
+f the poor workman hates his tools, the good workman hates poor
+tools. The work of the workingman is, in a sense, defined by his
+tools--witness the way in which the tool is so often taken to sym-
+bolize the worker: the tri-square for the carpenter, the trowel for
+the mason, the transit for the surveyor, the camera for the photog-
+*Taken from Portraits from Memory,Copyright 1951,1952,1953 and 1956,by Bertrand
+Russell. Reprinted by permission of Simon and Schuster and George Allen and Unwin, Ltd.
+203
+
+<!-- PDF page 260 -->
+204 
+Programming Tools 
+rapher, 
+the hammer for the laborer, 
+and the sickle 
+for the farmer. 
+Working with defective or poorly designed tools, even the finest craftsman 
+is reduced to producing inferior work, and thereby reduced to being an 
+inferior craftsman. No craftsman, if he aspires to the highest work in his 
+profession, will accept such tools; and no employer, if he appreciates the 
+quality of work, will ask a craftsman to accept them. 
+Is the situation any different in programming? At first glance it may 
+seem to be, but this misunderstanding can be traced to the relative im- 
+maturity of programming as compared to other crafts. The tools of any 
+trade evolve, but the tools of programming have had but a decade or two 
+to arrive at their present forms. Thus, there is no common standard for 
+programming tools, and no common experience in the use of the best 
+tools that do exist. 
+The programmer who is working in machine language—and many more 
+of these still exist than is commonly supposed—may not even be aware 
+of the advantages that the crudest assembly language can provide. In 
+our course on the psychology of computer programming, 
+one of the 
+students undertook an analysis of more than 2000 programming errors 
+encountered in his shop—where all programmers were coding in machine 
+language for a small special-purpose machine. Of these errors, 65 per- 
+cent were attributable to such housekeeping matters as inserting the 
+wrong number of no-ops for delay cycles, incorrect operation codes, er- 
+rors in placing a bit for such features as indirect addressing, using the 
+wrong absolute address, or incorrectly calculating a displacement. By 
+using an assembly language of the most primitive design, these program- 
+mers could have eliminated two-thirds of their coding errors—but they 
+did not even know that such a thing was possible. 
+As we move up the levels of possible programming aids, we find the 
+situation repeating itself, for although the assembly-language programmer 
+may scoff at the machine-language programmer, he may be in turn the 
+object of amusement for the user of a language with macro facilities. 
+Not all of this titillation, however, is attributable to the superiority of one 
+system over another. Much of it, indeed, 
+is a way of concealing 
+an 
+insecure feeling that one’s own programming system might not be, after 
+all, the pinnacle of man’s technological achievements. 
+In this section of the book, we shall attempt to examine the major tools 
+used by the programmer from the perspective of psychology, in order to 
+see if we cannot put questions of system design and selection out of 
+the reach of ignorant squabbling and squalling. No doubt we shall be 
+unable to achieve this high aim, but we hope to make at least a start in 
+a direction which promises more than some heretofore explored.
+
+<!-- PDF page 261 -->
+Silver Anniversary Notes 
+—X 
+Comments on 
+Part 4: 
+Programming Tools 
+When my old-timer’s eyes gaze upon today’s programming tools, | drool— 
+hopefully not merely out of decrepitude. Ah, imagine what we could have done 
+with such tools ...! Well, actually, we’d probably do just what we did, and what 
+any true professional would do—build more tools. 
+For most of my early career, | was engaged in building tools—operating sys- 
+tems; debugging tools; performance analyzers; static and dynamic code analyz- 
+ers; test generators, harnesses, and simulators; database systems; interpreters; 
+and the like. 
+Notice the omission of compilers. 
+For some reason, the field of 
+compiler-building never attracted me. There always seemed to be enough peo- 
+ple building compilers. 
+That much hasn’t changed; there are still more than 
+enough compiler-builders. 
+| did, however, have a great interest in supplementing compilers with metalan- 
+guages and other tools, so | made an excursion into MetaCOBOL. 
+With my 
+coauthors from Applied Data Research, | wrote a book about MetaCOBOL, 
+High-Level COBOL Programming. 
+The book was an experiment in using a 
+macro language as a transition device from COBOL to something better. On the 
+whole, the experiment didn’t work, and it was my last major effort at supplement- 
+ing languages with tools. 
+Superior tools only prolong the life of inferior lan- 
+guages. 
+For some years, | wrote a syndicated column for professional programmers as 
+a way of inspiring better tools and better use of existing tools. Some of these
+
+<!-- PDF page 262 -->
+PZ 
+Silver Anniversary Notes 
+columns are collected in Understanding the Professional Programmer and 
+Rethinking Systems Analysis & Design. 
+| doubt that these books and columns 
+had any measurable influence on the development of better tools—certainly not 
+compared with the influence the personal computer had. 
+Back in the 1950’s and early 1960’s, programming tools were largely designed 
+and made by users. 
+For example, when we built the very first operating sys- 
+tems, we did so as a cooperative effort among various IBM customers. IBM was 
+involved (as was I, as an IBM employee), but only as one of the cooperators. 
+So, at that time, all of our tools were distributed free by the SHARE organization 
+or bundled with IBM’s hardware. 
+By the late 1960’s, a successful legal challenge was mounted against the con- 
+cept of bundled software—led by Marty Goetz at ADR, one of my coauthors in 
+the MetaCOBOL effort. The challenge made software available for sale (or rent), 
+but initially left the hardware manufacturers largely in control of the programming 
+tools business. 
+In the 1980’s, PCs changed all that by democratizing tool-building again, 
+putting it back in the hands of the tool users and enabling real competition 
+among tools. That competition has increased the appeal of tools while lowering 
+their price. 
+That’s why, to old-timers like me, today looks like a utopia of pro- 
+gramming tools.

library/The Psychology of Computer Programming/Interlude-Part-5-Epilogue/Interlude-source-text.md

@@ -0,0 +1,331 @@
+# The Psychology of Computer Programming — Interlude: Part 5: Epilogue
+- **Source**: /library/The Psychology of Computer Programming/source-file.pdf
+- **PDF pages**: 340–346
+- **Pages without text**: 341, 342
+- **OCR note**: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
+- **Note**: Original epilogue and Silver Anniversary comments on the epilogue.
+
+---
+
+<!-- PDF page 340 -->
+mucltortie 9 sat 
+ioe at 
+dimen “heide treat: signa meesaée 
+ete syateaay hit Hor weiner iat 
+¢: ad mt vegiuiere coaciper: ii\viniadnaaen 
+ow 
+vein son hatit | angnegigaleesaalianl 
+a> necinl 93 er a 21008 
+aint Peaoaphievadga 2h 
+i 
+oktowd edhotol 
+Jepamanarigirat: onlt, nen hn 
+LAG Kiara 
+iy Ver neat Dooe aE ist 
+perth 
+RASCH A) a ie vesealio aga ts share 
+od swbroer 
+| sone mPMONE acl neler tent 
+PTE A Pd he cata’ oO 
+SCORPIO 
+HORS espe Sas care ROY a ROR 
+iho 
+Ren Dsere gems Biant Dart fag 
+detect, 
+it oe ; 0 
+‘ 
+se “i 
+ie Ate reds spate atth op snoiratneceae semen uae 
+A 
+ma sre 
+grey Series eltiey 
+Leatlaat 4 eine ‘ 
+aA ye 
+kui 
+ton aleve! 
+Dachinethateeaadinaainigtiaen 
+eas 
+pester 
+fC 
+RRO ap 
+Bie Rly Jat ori. ce eae 
+er Tae 
+a 
+Nor} 
+as Ed 
+Ae 
+ye Thee Lh TQ atl 
+on 
+eS 
+oiceben 
+1 sobeece notes haibetibey aera 
+(hort ootagie iatartemtag mat SP MAAIO I 
+im 
+POND, 
+HORNY Mean Wing triage = acpi cay reiting 
+JA ee 
+qones oteta Sei Cee: ising 
+ve 
+Rare Cee ia "ROD Riscehh ae 
+LAO Ce i 
+ee - a 
+tw (att 
+ut inet 
+i m 
+diy hs a 
+od 
+nore 
+ra) et? 
+bil ies 
+al be Riek ene ~ 
+. 
+nha 
+ug xn 
+bila, r 
+n 
+, 
+‘ey 
+a 
+Do 
+x wit? “a 
+csr. jee 
+a mac 
+i 
+“ene chien sin gihallica hace 
+rottuty 
+, 
+ry 
+us 
+(its ri ts 
+ate “ 
+Br he er Boi 
+; 
+idied aA “al 
+S58 
+10/7) Ga ao 
+hs 
+{ dewpiie orth a hirefecpee 
+it 
+: 
+7 
+g2 
+FaDi. 
+made 
+obse Gh by naghel 14 ied } é 
+COURS, ie 
+SOD ath te ee 
+op. th & orig bon 2 
+fo 
+wid py Sbenidnal gine ‘oties debited. ua 
+ui 
+AFL HORE BOG on ¥ 
+iraciad Al ry 
+cramming veyod the inna. 
+fa 
+ea 
+: 
+%, 
+ste te 
+ve"? 
+rege 
+HIVES Weyer? m4 x Eee 
+agin 
+on t 
+“a 
+Tie SOgTeY 1K, : Fat one 
+AM, 
+yy 
+ee 
+a 
+' 
+. 
+5 
+‘ 
+bg 
+a 
+m 
+vi 
+s) 
+a 
+i 
+i@ 
+«®, 
+af 
+a= - 
+} 
+‘ 
+Pep 
+4 
+¢ 
+¥ 
+re 
+i 
+ay 
+A 
+aD 
+oh” ae 
+TS 
+ee 
+ad cal 
+J 
+Ae 
+= 
+a a
+
+<!-- PDF page 341 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+PART
+EPILOGUE
+
+<!-- PDF page 342 -->
+[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
+
+[Image-only page; OCR found no readable text. Consult the PDF for visual content.]
+
+<!-- PDF page 343 -->
+eaders who reach the end of a book are entitled to some praise 
+from the author, since they have paid him the greatest compli- 
+ment an author can receive. Yet those readers who do reach the 
+end are probably in less need of rewards than the dropout, for it 
+would seem impossible to go all the way through any book without receiv- 
+ing the reward of learning. Perhaps it is possible to go through this book 
+without 
+being touched, 
+although 
+as one 
+reviewer commented, 
+‘One 
+comes away with the feeling of having spent a pleasant but somewhat 
+‘wasted’ afternoon of reading, and as the old joke goes, ‘it ain’t till you 
+try to turn your head that you realize how sharp the razor was.’”’ Al- 
+though | would have been happier with a less violent metaphor, the re- 
+mark captures what the book has tried to do. My students have had the 
+same reaction. A typical remark made a year after attending a seminar 
+is: “It was pleasant enough talking about those things, but then | began 
+to see what was going on at the office. Wow!” 
+The most important thing that this student learned was not any par- 
+ticular behavioral science result or the name of so-and-so’s law to parrot 
+back on a test. What he learned was that he had been carrying around 
+with him all his life a well-equipped machine for observing behavior— 
+but that it had never been used very much. As an anonymous sign at the 
+computing center put it: 
+' The human mind ordinarily operates at only ten percent of its capacity—the 
+rest is overhead for the operating system. 
+So rather than be concerned so much about that computer operating 
+277
+
+<!-- PDF page 344 -->
+278 
+Epilogue 
+system, the reader who has really been touched by this book will start to 
+work on the operating system he carries around in his own central proc- 
+essihg unit—his head. That will be his reward. 
+But if we make our own operating systems more efficient, if we observe 
+ourselves and our surroundings more carefully, and if this efficiency and 
+observation lead us to be more productive programmers, of what use is 
+it? The stories of the three wishes send us a message from many Ccul- 
+tures, and from the ancient past: “If you get your fondest wish, what 
+then?” 
+If, by psychological, sociological, and anthropological investiga- 
+tion or by simple heightened awareness we become better programmers, 
+to what work shall we turn our talents? For if something is not worth 
+doing, it is certainly not worth doing right. 
+Is what we are doing with computers worth doing? Is what you are 
+doing with computers worth doing? Because computers are such fascinat- 
+ing beasts, because programming 
+is such a game, such a joy, we who 
+program computers are in danger of becoming the unwitting pawns of 
+those who would use our toys for not-so-playful ends. Can there be any 
+doubt that 
+if Hitler had computers 
+at his command, one of the first 
+application would have been keeping closer track on Jews and Gypsies 
+so that all who should have gone to the ovens did go to the ovens? Can 
+there by any doubt that if Pilate had computers, they would have been 
+used to keep the information from informers, the better to crucify those 
+that were crying out for crucifixion by their heretical zeal? Can there be 
+any doubt that somewhere in our country today some human beings are 
+using computers as just another, finer weapon in their arsenal of ways 
+to subjugate other human beings to their wishes—to their conception of 
+the proper life of man? 
+And having said all that, can there be any doubt that such people— 
+now as in 1939 or at the dawn of the Christian era—find many willing 
+hands and brains to carry out their work in return for fun and profit? Or 
+that some of those willing hands will have held this book, to the profit 
+of their employers? 
+Many years ago, just a few years after | wrote my first book with Herb 
+Leeds, | read an article describing experiments in which monkeys were 
+subjected to various doses of poison gases, evidentally to see how long 
+it took them to die. The work was done in a laboratory for chemical war- 
+fare research, with the intent, no doubt, of extrapolating 
+it to human 
+beings. Thirty-six innocent monkeys, as | recall, met their deaths in this 
+gruesome way so that someday, perhaps, thirty-six million people could 
+meet their deaths even more efficiently. The article remained in my mind 
+for months afterward, and indeed it has remained there to this day. By 
+pure coincidence, 
+| suppose, 
+| was accosted 
+at a meeting by a nice 
+young man who had gone out of his way to tell me how much he had
+
+<!-- PDF page 345 -->
+Epilogue 
+279 
+learned from our book, how much it had helped him to become a better 
+programmer. | asked him what sort of work he did, and he replied that 
+he worked at a laboratory for chemical warfare research. 
+Afterward, 
+| tried to rationalize my way out of my depression by 
+imagining that it was a different laboratory, which it might have been, or 
+that he never worked on the monkey experiment, which might also have 
+been true. But | knew that somewhere, someone who had learned from 
+me was participating in such experiments and worse. | knew that | shared 
+the responsibility—that writing a book is not merely teaching means to 
+unknown and unimagined ends. For a long time | could not write, perhaps 
+for that reason, or perhaps for others. But, eventually, my ego got the 
+better of me and | began again, determined to try making my books 
+unusable to any but the pure at heart. 
+To a certain extent, this book may have achieved that goal, for the 
+idea of the programmer as a human being is not going to appeal to cer- 
+tain types of people, and they will neither finish the book nor profit from 
+it. But it is naive, | now realize, to expect that bad systems cannot be 
+built by people with good hearts. Otherwise, why would | encounter so 
+many bad systems when almost all of the people | meet are wonderful? 
+No, something else is needed, something not within the power of an 
+author to give to a reader. As Malraux once said, “It is the work of a 
+lifetime to make a man.” A book can be but a tiny part of that work— 
+the rest is up to you, and the work will never be finished. 
+Having said all that, | do not shrink from personal responsibility for 
+what | have done in writing this book. We stand at the brink of a new age, 
+an age made possible by the revolution that is embodied in the computer. 
+Standing on the brink, 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 efforts 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 the 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, | can only hope that its use to the other 
+forces will, in the balance, be greater.
+
+<!-- PDF page 346 -->
+SS 
+Silver Anniversary Notes 
+Comments on 
+Part 5: Epilogue 
+This Epilogue has stood the test of time, and | have nothing to add. 
+As a new epilogue for this Silver Anniversary Edition, however, I’d like to invite 
+you to do two things that | wasn’t able to offer twenty-five years ago. 
+First, if you’d like to Keep current on what I’m doing and thinking, writing and 
+teaching, | invite you to visit my website: 
+http://www.geraldmweinberg.com 
+Second, if you’d like to share some of your ideas, observations, or experi- 
+ences with me, go to my website and send me e-mail. 
+You should always be 
+able to reach me from there, at least as long as |’m still around. 
+Hopefully, that 
+will be long enough for me to write a Golden Anniversary Edition of The 
+Psychology of Computer Programming.

library/The Psychology of Computer Programming/book-structure.md

@@ -0,0 +1,43 @@
+# The Psychology of Computer Programming — Book Structure
+
+- **Author**: Gerald M. Weinberg
+- **Edition**: Silver Anniversary Edition (1998; original edition 1971)
+- **Source format**: PDF scan with an OCR text layer
+- **PDF length**: 364 pages
+- **Numbered chapters**: 13
+- **Extraction date**: 2026-10-23
+
+## Structure and Page Map
+
+| Section | Title | PDF pages | Printed start | Source text |
+| --- | --- | ---: | ---: | --- |
+| Front Matter | Contents, Silver Anniversary preface, original preface, and course-use suggestions | 1-25 | — | `/library/The Psychology of Computer Programming/Front-Matter/Front-Matter-source-text.md` |
+| Part 1 | Programming as Human Performance | 26-30 | 2 | `/library/The Psychology of Computer Programming/Interlude-Part-1-Programming-as-Human-Performance/Interlude-source-text.md` |
+| Chapter 1 | Reading Programs | 31-42 | 5 | `/library/The Psychology of Computer Programming/Chapter-01-Reading-Programs/Chapter-01-source-text.md` |
+| Chapter 2 | What Makes a Good Program? | 43-56 | 15 | `/library/The Psychology of Computer Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-source-text.md` |
+| Chapter 3 | How Can We Study Programming? | 57-76 | 27 | `/library/The Psychology of Computer Programming/Chapter-03-How-Can-We-Study-Programming/Chapter-03-source-text.md` |
+| Part 2 | Programming as a Social Activity | 77-82 | 44 | `/library/The Psychology of Computer Programming/Interlude-Part-2-Programming-as-a-Social-Activity/Interlude-source-text.md` |
+| Chapter 4 | The Programming Group | 83-106 | 47 | `/library/The Psychology of Computer Programming/Chapter-04-The-Programming-Group/Chapter-04-source-text.md` |
+| Chapter 5 | The Programming Team | 107-138 | 67 | `/library/The Psychology of Computer Programming/Chapter-05-The-Programming-Team/Chapter-05-source-text.md` |
+| Chapter 6 | The Programming Project | 139-162 | 95 | `/library/The Psychology of Computer Programming/Chapter-06-The-Programming-Project/Chapter-06-source-text.md` |
+| Part 3 | Programming as an Individual Activity | 163-168 | 118 | `/library/The Psychology of Computer Programming/Interlude-Part-3-Programming-as-an-Individual-Activity/Interlude-source-text.md` |
+| Chapter 7 | Variations in the Programming Task | 169-190 | 121 | `/library/The Psychology of Computer Programming/Chapter-07-Variations-in-the-Programming-Task/Chapter-07-source-text.md` |
+| Chapter 8 | Personality Factors | 191-212 | 141 | `/library/The Psychology of Computer Programming/Chapter-08-Personality-Factors/Chapter-08-source-text.md` |
+| Chapter 9 | Intelligence, or Problem-Solving Ability | 213-233 | 161 | `/library/The Psychology of Computer Programming/Chapter-09-Intelligence-or-Problem-Solving-Ability/Chapter-09-source-text.md` |
+| Chapter 10 | Motivation, Training, and Experience | 234-256 | 180 | `/library/The Psychology of Computer Programming/Chapter-10-Motivation-Training-and-Experience/Chapter-10-source-text.md` |
+| Part 4 | Programming Tools | 257-262 | 202 | `/library/The Psychology of Computer Programming/Interlude-Part-4-Programming-Tools/Interlude-source-text.md` |
+| Chapter 11 | Programming Languages | 263-276 | 205 | `/library/The Psychology of Computer Programming/Chapter-11-Programming-Languages/Chapter-11-source-text.md` |
+| Chapter 12 | Some Principles for Programming Language Design | 277-307 | 217 | `/library/The Psychology of Computer Programming/Chapter-12-Some-Principles-for-Programming-Language-Design/Chapter-12-source-text.md` |
+| Chapter 13 | Other Programming Tools | 308-339 | 246 | `/library/The Psychology of Computer Programming/Chapter-13-Other-Programming-Tools/Chapter-13-source-text.md` |
+| Part 5 | Epilogue | 340-346 | 275 | `/library/The Psychology of Computer Programming/Interlude-Part-5-Epilogue/Interlude-source-text.md` |
+| Back Matter | Index, publisher catalog, and back cover | 347-364 | 281 | `/library/The Psychology of Computer Programming/Back-Matter/Back-Matter-source-text.md` |
+
+## Extraction Notes
+
+- Every PDF page from 1 through 364 appears in exactly one source-text file; there are no gaps or overlaps.
+- Each chapter includes Weinberg's Silver Anniversary commentary immediately following the original chapter.
+- Part introductions and the epilogue are stored as non-chapter interludes.
+- Pages without native text: 1, 2, 25, 27, 77, 165, 258, 259, 341, and 342.
+- OCR was added for content-bearing pages 1, 25, 27, 165, 258, 259, and 341. Pages 2, 77, and 342 are blank or near-blank; their markers remain for complete coverage.
+- The PDF's inherited OCR layer is noisy on some pages, especially decorative dividers, drop caps, formulas, and figures. Consult the source PDF when exact typography or a visual element matters.
+

library/The Psychology of Computer Programming/ocr-image-pages.json

@@ -0,0 +1,12 @@
+{
+  "1": "THE\nPSYCHOLOGY\nCOMPUTER\nPROGRA MMING\nSILVER ANNIVERSARY\nEDITION\nDH\nGERALD M. WEINBERG",
+  "2": "[Image-only page; OCR found no readable text. Consult the PDF for visual content.]",
+  "25": "THE\nPSYCHOLOGY\nOF\nCOMPUTER\nPROGRAMMING\nSILVER ANNIVERSARY\nEDITION",
+  "27": "The important thing is not to stop questioning.\nCuriosity has its own reason for existing. One can-\nnot help but be in awe when he contemplates the\nmysteries of eternity, of life, of the marvelous struc-\nture of reality. It is enough if one tries to compre-\nhend a little of this mystery every day. Never lose\na holy curiosity.\nAlbertEinstein*\nomputer programming is a human activity. One could hardly dis-\npute this assertion, and yet, perhaps because of the emphasis\nplaced on the machine aspects of programming, many people\n-many programmers-have never considered programming in\nthis light. Among programmers, there is a certain mystique--a certain\nwaving of the hands which takes place whenever one tries to probe the\nmanner in which programming is done. Programming is not done in a\ncertain way, they say, it is just done. Either you can program or you\ncannot. Some have it; some don't.\nOne of the corollaries of this mystique is the high salaries that must\nbe paid. to those programmers who *have it\"---and even to some who\n* From Death of a Genius, by William Miller, LIFE Magazine, May 2, 1955 C 1955 Time Inc.",
+  "77": "[Image-only page; OCR found no readable text. Consult the PDF for visual content.]",
+  "165": "I have in mind the only liberty worthy of that\nname, liberty consisting in the full development of\nall the material, intellectual, and moral powers latent\nin every man; a liberty which does not recognize\nany other restrictions but those which are traced\nby the laws of our own nature, which, properly\nspeaking, is tantamount to saying that there is no\nrestriction at all..\nMikhail Bakunin*\nt the beginning of this book,'we set out to account for some\nprogrammers. We have seen that much of that variance can\nbe accounted for by social factors-much more than we might\nhave believed from casual considerations. But, no matter how much\nvariance is attributable to social factors, there will always remain\na residue. No matter how similar the structure of two programming groups\nmight be, they will produce different finished products. In this section,\nwe shall try to account for some of those differences by examining factors\ncentering in and around the individual.\n*Reprinted with the permission of Macmillan Company. From The Political Philosophy ot\nBakunin, by M. A. Bakunin. Copyright 1953, 1964 by the Free Press.\n119",
+  "258": "PART\nTOOLS",
+  "259": "a word of advice to such of my hearers as\nmay happen to be professors.I am allowed to use\nplain English because everybody knows that !\ncoulid use mathematical logic if I chose. Take the\nstatement: \"Some people marry their deceased\nwives' sisters.\" 1 can express this in language\nwhich only becomes intelligible after years of\nstudy, and this gives me freedom. I suggest to\nyoung professors that their first work should be\nwritten in a jargon only to be understood by the\nerudite few. With that behind them, they can ever\nafter say what they have to say in a language\n\"understanded by the people.\" In these days, when\nour very lives are at the mercy of professors,I\ncannot but think that they would deserve our grati-\ntude if they adopted my advice.\nBertrandRussell*\nf the poor workman hates his tools, the good workman hates poor\ntools. The work of the workingman is, in a sense, defined by his\ntools--witness the way in which the tool is so often taken to sym-\nbolize the worker: the tri-square for the carpenter, the trowel for\nthe mason, the transit for the surveyor, the camera for the photog-\n*Taken from Portraits from Memory,Copyright 1951,1952,1953 and 1956,by Bertrand\nRussell. Reprinted by permission of Simon and Schuster and George Allen and Unwin, Ltd.\n203",
+  "341": "PART\nEPILOGUE",
+  "342": "[Image-only page; OCR found no readable text. Consult the PDF for visual content.]"
+}

tools/split_book.py

@@ -413,6 +413,70 @@ def build_code_of_discipline():
     return secs
 
 
+def build_psychology_of_computer_programming():
+    # The Silver Anniversary Edition is a scanned book without bookmarks. Each numbered
+    # chapter is followed by Weinberg's anniversary commentary, which stays with that
+    # chapter. Part introductions and the epilogue remain separate non-chapter sections.
+    chapters = [
+        (1, "Reading Programs", 31, 42),
+        (2, "What Makes a Good Program?", 43, 56),
+        (3, "How Can We Study Programming?", 57, 76),
+        (4, "The Programming Group", 83, 106),
+        (5, "The Programming Team", 107, 138),
+        (6, "The Programming Project", 139, 162),
+        (7, "Variations in the Programming Task", 169, 190),
+        (8, "Personality Factors", 191, 212),
+        (9, "Intelligence, or Problem-Solving Ability", 213, 233),
+        (10, "Motivation, Training, and Experience", 234, 256),
+        (11, "Programming Languages", 263, 276),
+        (12, "Some Principles for Programming Language Design", 277, 307),
+        (13, "Other Programming Tools", 308, 339),
+    ]
+    chapter_note = (
+        "Includes the Silver Anniversary comments that immediately follow the original chapter. "
+        "Text comes from the scan's OCR layer and may contain recognition errors."
+    )
+    secs = [(
+        "Front-Matter",
+        "Front matter, contents, Silver Anniversary preface, original preface, and course-use suggestions",
+        1,
+        25,
+        "Silver Anniversary Edition (1998).",
+    )]
+    parts = {
+        1: ("Programming as Human Performance", 26, 30),
+        4: ("Programming as a Social Activity", 77, 82),
+        7: ("Programming as an Individual Activity", 163, 168),
+        11: ("Programming Tools", 257, 262),
+    }
+    for number, title, start, end in chapters:
+        if number in parts:
+            part_title, part_start, part_end = parts[number]
+            secs.append((
+                "Interlude",
+                f"Part {len([n for n in parts if n <= number])}: {part_title}",
+                part_start,
+                part_end,
+                "Part introduction and Silver Anniversary comments on the part.",
+            ))
+        secs.append((ch(number), title, start, end, chapter_note))
+    secs.append((
+        "Interlude",
+        "Part 5: Epilogue",
+        340,
+        346,
+        "Original epilogue and Silver Anniversary comments on the epilogue.",
+    ))
+    secs.append((
+        "Back-Matter",
+        "Index, publisher catalog, and back cover",
+        347,
+        364,
+        "",
+    ))
+    return secs
+
+
 WATTLES_WORKS = [  # (title bookmark, short name)
     ("The Science of Getting Rich", "The Science of Getting Rich"),
     ("The Science of Being Well", "The Science of Being Well"),
@@ -490,6 +554,7 @@ BUILDERS = {
     "The Direct Mail Solution": build_direct_mail_solution,
     "The Hype Handbook": build_hype_handbook,
     "The Code of Discipline": build_code_of_discipline,
+    "The Psychology of Computer Programming": build_psychology_of_computer_programming,
     "Wallace D. Wattles Ultimate Collection": build_wattles,
 }