Good code is rarely read
An essay claiming that “good code is rarely read” provokes debate over what actually makes software quality: is it code that almost never needs to be touched, or code that is easy to understand and modify when requirements inevitably change? Commenters argue that in long‑lived, evolving systems, readability and maintainability are essential because business needs, dependencies, and laws shift over time, forcing frequent changes even to well‑designed components. Many conclude that code quality and how often code is read are largely independent, and that striving for clear abstractions and readable internals remains critical regardless of how frequently a given module is opened.
Overall reaction to “good code is rarely read”
- Many commenters reject the headline as a general rule; they argue all non-trivial code is eventually revisited.
- Others see it as provocative wordplay: “good code is rarely read twice” or “good APIs mean you rarely read the implementation.”
- Several note the statement borders on tautological: defining good code by its effects (“needing less reading”) rather than concrete qualities.
Readability, maintenance, and changing requirements
- Strong consensus that readability and ease of modification are central to code quality.
- Long-lived and internal systems continually change due to new business requirements, laws, external APIs, and stakeholder shifts.
- Because such evolution is inevitable, code that is easy to understand, test, and modify is valued more than code that is just “not touched.”
- Clever or premature abstractions and aggressive DRY can harm readability and future changes.
Abstractions, APIs, and “rarely read” code
- Many distinguish implementation from interface: good libraries, frameworks, and “leaf” modules often have stable APIs that are used heavily without reading internals.
- Examples cited include database clients, collections, executors, engines, and low-level utilities: they can be complex inside but simple and stable outside.
- Others counter that widely used core libraries (e.g., SQLite, major C++ libraries) are heavily read and studied despite being considered exemplary.
Frequency vs. effort of reading
- Some suggest the key metric is time/effort spent reading, not raw frequency.
- Good code can be read quickly and understood in a single pass; bad code forces repeated, painstaking re-reading and “human interpretation.”
- The “WTF per minute” notion appears as a humorous shorthand for this.
Code reading as learning and diagnosis
- Several participants emphasize reading code as essential for:
- Debugging mismatches between behavior and documentation.
- Onboarding, understanding systems, and discovering reuse opportunities.
- Learning better styles and patterns from high-quality examples.
- Concern is raised that if “good code is rarely read,” people may disproportionately internalize patterns from bad code they must slog through.