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)

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.

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.

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.