Good code is rarely read

Original Article ↗ Hacker News Discussion ↗

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.