Add Psychology of Computer Programming workspace

il y a 11 heures · 82d8acb86a
--- a/MEMORY.md
+++ b/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
--- a/Programming/Back-Matter/Back-Matter-source-text.md
+++ b/Programming/Back-Matter/Back-Matter-source-text.md
--- a/Programming/Chapter-01-Reading-Programs/Chapter-01-chapter-notes.md
+++ b/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.

--- a/Programming/Chapter-01-Reading-Programs/Chapter-01-memory.md
+++ b/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.

--- a/Programming/Chapter-01-Reading-Programs/Chapter-01-source-text.md
+++ b/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
--- a/Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-chapter-notes.md
+++ b/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

--- a/Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-memory.md
+++ b/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.
--- a/Programming/Chapter-02-What-Makes-a-Good-Program/Chapter-02-source-text.md
+++ b/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.
--- a/Programming/Chapter-03-How-Can-We-Study-Programming/Chapter-03-source-text.md
+++ b/Programming/Chapter-03-How-Can-We-Study-Programming/Chapter-03-source-text.md
--- a/Programming/Chapter-04-The-Programming-Group/Chapter-04-source-text.md
+++ b/Programming/Chapter-04-The-Programming-Group/Chapter-04-source-text.md
--- a/Programming/Chapter-05-The-Programming-Team/Chapter-05-source-text.md
+++ b/Programming/Chapter-05-The-Programming-Team/Chapter-05-source-text.md
--- a/Programming/Chapter-06-The-Programming-Project/Chapter-06-source-text.md
+++ b/Programming/Chapter-06-The-Programming-Project/Chapter-06-source-text.md
--- a/Programming/Chapter-07-Variations-in-the-Programming-Task/Chapter-07-source-text.md
+++ b/Programming/Chapter-07-Variations-in-the-Programming-Task/Chapter-07-source-text.md
--- a/Programming/Chapter-08-Personality-Factors/Chapter-08-source-text.md
+++ b/Programming/Chapter-08-Personality-Factors/Chapter-08-source-text.md
--- a/Programming/Chapter-09-Intelligence-or-Problem-Solving-Ability/Chapter-09-source-text.md
+++ b/Programming/Chapter-09-Intelligence-or-Problem-Solving-Ability/Chapter-09-source-text.md
--- a/Programming/Chapter-10-Motivation-Training-and-Experience/Chapter-10-source-text.md
+++ b/Programming/Chapter-10-Motivation-Training-and-Experience/Chapter-10-source-text.md
--- a/Programming/Chapter-11-Programming-Languages/Chapter-11-source-text.md
+++ b/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).
--- a/Programming/Chapter-12-Some-Principles-for-Programming-Language-Design/Chapter-12-source-text.md
+++ b/Programming/Chapter-12-Some-Principles-for-Programming-Language-Design/Chapter-12-source-text.md
--- a/Programming/Chapter-13-Other-Programming-Tools/Chapter-13-source-text.md
+++ b/Programming/Chapter-13-Other-Programming-Tools/Chapter-13-source-text.md
--- a/Programming/Front-Matter/Front-Matter-source-text.md
+++ b/Programming/Front-Matter/Front-Matter-source-text.md
--- a/Programming/Interlude-Part-1-Programming-as-Human-Performance/Interlude-source-text.md
+++ b/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
--- a/Programming/Interlude-Part-2-Programming-as-a-Social-Activity/Interlude-source-text.md
+++ b/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.”
--- a/Programming/Interlude-Part-3-Programming-as-an-Individual-Activity/Interlude-source-text.md
+++ b/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.
--- a/Programming/Interlude-Part-4-Programming-Tools/Interlude-source-text.md
+++ b/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.
--- a/Programming/Interlude-Part-5-Epilogue/Interlude-source-text.md
+++ b/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.
--- a/Programming/book-structure.md
+++ b/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.

--- a/Programming/ocr-image-pages.json
+++ b/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.]"
 }
--- a/Programming/source-file.pdf
+++ b/Programming/source-file.pdf
--- a/tools/split_book.py
+++ b/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,
 }