Cognitive load is what matters

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.