#Code Readability

Code Is Primarily Written for Human Readers

Because syntax alone rarely conveys purpose, programs need signals that communicate intent: meaningful identifiers, well-chosen abstractions, and comments that explain “why” rather than restate “what.” This is where Abelson’s point gains practical force—humans infer goals and invariants, while machines only follow instructions. A function named calculate_total_with_tax communicates direction before a reader opens it; a name like doStuff does the opposite. Consequently, good code often reads like an argument: it introduces concepts, builds them up, and uses them consistently so the reader can predict what comes next. [...]

Code Is Communication Before It Is Execution

Once we accept code as communication, the constraints change: machines have no trouble with verbosity, indirection, or awkward naming, but humans do. A compiler will happily execute dense expressions and cryptic variables; a teammate returning six months later will pay the cost in misread assumptions and fragile changes. Consequently, most engineering effort shifts from initial creation to ongoing modification. Frederick P. Brooks’ “The Mythical Man-Month” (1975) emphasizes that software complexity compounds coordination and understanding costs; Abelson’s quote lands on the same pressure point, suggesting that clarity is not aesthetic—it is an efficiency strategy for the real limiting resource: human attention. [...]