# 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.