Cognitive load is what matters

Original Article ↗ Hacker News Discussion ↗

Cognitive load—the mental effort required to understand and change code—emerges as a more meaningful target than raw metrics like lines of code, number of clicks, or “10x engineer” mythology. Commenters argue that abstractions, language features, architecture, and even tooling should be judged by how much they let developers reason locally with a few concepts at a time, favoring clear interfaces, simple functions where they genuinely help, and avoiding over-layered, “clever” designs that fragment logic or hide state. There is broad support for ideas like composition over inheritance and strong typing when they reduce surprise, alongside pushback that “cognitive load” is sometimes invoked loosely and that what feels simple can be highly context- and experience-dependent.

Cognitive Load as Central Concern

  • Many agree “cognitive load” is a better north star than raw metrics (lines, clicks, layers, etc.).
  • Aim is to keep the number of actively relevant concepts small so changes can be made without “whack‑a‑mole” bugs.
  • Both intrinsic complexity (domain difficulty) and extrinsic complexity (bad design, boilerplate, noise) matter.

Measuring and Explaining Cognitive Load

  • Proposed metrics:
    • Cyclomatic complexity for local control‑flow difficulty.
    • Architectural complexity for dependency visibility and coupling between modules.
  • Working‑memory limits (~4–7 items) are cited as justification for aggressive simplification, though some call the article’s use of “cognitive load theory” superficial.
  • Several stress that cognitive load is partly subjective: familiar styles and idioms feel cheaper than objectively “cleaner” but unfamiliar ones.

Languages, Syntax, Types, and Boilerplate

  • Feature‑rich languages can reduce cognitive load once internalized; others counter that excessively large or poorly designed languages (C++, Swift) become load sources.
  • Long debate on semicolons and syntactic redundancy:
    • One side: redundancy (semicolons, explicit braces, type hints) catches errors and improves readability.
    • Other side: required but inferable syntax and boilerplate are pure unnecessary load.
  • Static typing is seen by many as a major load reducer (don’t track types in your head); others favor optional/gradual typing and dynamic systems (Lisp, Clojure) plus powerful REPLs and macros.

Abstractions, Function Size, and Local Reasoning

  • Strong disagreement on tiny methods and deep class hierarchies:
    • Critics: too many shallow modules and one‑line methods create indirection, emergent complexity, and “function‑jumping” overhead.
    • Supporters: small, well‑named functions encode intent, isolate side effects, and make unit testing and reuse easier; you usually don’t need to read implementation unless troubleshooting.
  • Repeated theme: good abstractions are those chosen to reduce cognitive load, not just to reduce duplication or satisfy line‑count rules.
  • Comments vs helper functions:
    • Some prefer named helpers over comments.
    • Others argue that sometimes a single longer, clearly structured function (with comments) is lower load than a swarm of helpers.

Architecture, Layering, and Dependencies

  • Layered architectures and microservices:
    • Over‑layering and over‑splitting services are criticized for adding network, deployment, and tracing complexity without proportional benefit.
    • Others argue that clear separation between domain logic and infrastructure (ports/adapters, dependency inversion) greatly eases testing, evolution, and database/framework migration.
  • Consensus: abstractions around external dependencies are valuable, but “architecture astronautics” and premature layering increase cognitive load.

Tools, Workflow, and Environment

  • Highly customized setups (tiling WMs, heavy Vim/Neovim workflows) can either reduce load via muscle memory or increase it if not truly mastered.
  • Cognitive load is also impacted by:
    • Interruptions (Slack, meetings) and context switching.
    • Overbearing processes: strict line limits, DRY absolutism, and tiny‑PR mandates can cause excessive overhead and frustration.

LLMs and Changing Heuristics

  • With LLM‑assisted coding:
    • Several suggest internal function complexity may matter less if tests are good and scopes are small.
    • Interfaces, contracts, and module boundaries become even more crucial so humans (and LLMs) can reason about system‑level behavior without diving into every function.