code-that-fits-in-your-head

name

code-that-fits-in-your-head

description

Software engineering heuristics from Mark Seemann's book Code That Fits in Your Head (2021). Use when writing new code, reviewing code, refactoring, designing APIs, handling validation and invariants, writing unit tests, debugging defects, performing security review (STRIDE), or setting up a new code base. Covers decomposition (cyclomatic complexity, 80/24 rule, cohesion, fractal architecture), encapsulation (invariants, parse-don't-validate, Postel's law), outside-in TDD (walking skeleton, AAA, triangulation, devil's advocate), API design (affordance, poka-yoke, CQS), git/PR hygiene (50/72 commits, small commits, code review), feature flags, Strangler pattern, bisection debugging, logging with decorators, and STRIDE threat modelling. Not for language-specific syntax, framework tutorials, production incident response, or performance profiling.

Code That Fits in Your Head

Engineering heuristics for sustainable software, based on Mark Seemann's 2021 book.

Philosophy (Why This Skill Exists)

Software development is principally a design activity, not construction. Code is written by people, read by people, and endures far longer than any "project". These heuristics are rules of thumb (not scientific laws) that make software sustainable — that is, cheap to change and resilient to the next 10,000 small decisions.

Core mental model from Chapter 1:

Metaphor	What it gets right	What it misses
Building a house	Plans, structure	Software endures; there's no construction phase (compiling is free); dependencies can start anywhere
Growing a garden	Pruning, refactoring, tending	Code doesn't grow by itself — someone writes it
Art / craft	Skill, mastery, situational knowledge	Doesn't scale; leaves newcomers without guidance
Engineering (the target)	Heuristics, review, sign-off, checklists	We're not there yet — physical-construction calculations don't apply

"The act of describing a program in unambiguous detail and the act of programming are one and the same." — Kevlin Henney

Practical implications for a code agent:

1. Successful software endures. Prefer changes that don't lock the future; avoid "finish-and-forget" thinking.
2. Heuristics, not laws. Every rule in this skill has context. Understand why before deviating. When the user asks to break a rule, check if their reason addresses the rule's rationale.
3. Design = typing code. Code review, naming, function size, and API shape are the primary design surfaces.
4. The future is unevenly distributed. Techniques described here (CI, tests, checklists, STRIDE) exist today — adopt them per-context rather than arguing for greenfield-only use.

See references/foundations/ for more on sustainability, readability, and brain-limited design.

How to Use This Skill

1. Identify the user's task (writing, reviewing, debugging, security review, setting up, etc.)
2. Read guidelines.md — it maps tasks and symptoms to specific reference files
3. Load only the reference files relevant to the current task (progressive disclosure)
4. Apply the rules; when in doubt, consult references/practices-glossary/ for cross-references

Chapter Index

Topic	Use when...
references/foundations/	Understanding why code should fit in head; sustainability, readability, humane code
references/codebase-setup/	Starting or inheriting a code base — git, build automation, warnings-as-errors
references/outside-in-tdd/	Writing new features test-first; walking skeleton, AAA, triangulation, devil's advocate, editing tests
references/encapsulation/	Designing types with invariants; DTO vs Domain Model, always-valid, Postel's law, parse-don't-validate
references/decomposition/	Splitting a function/class; cyclomatic complexity, 80/24 rule, cohesion, feature envy, fractal architecture, composition
references/api-design/	Designing a public API; affordance, poka-yoke, CQS, hierarchy of communication, naming over comments
references/separation-of-concerns/	Adding cross-cutting concerns; Decorator pattern, logging, what to log, performance vs legibility
references/teamwork-git/	Writing commits, reviewing PRs; 50/72 rule, small commits, continuous integration, pair/mob, code review
references/evolution/	Changing running systems; feature flags, Strangler pattern, versioning, regular dependency updates, Conway's law
references/troubleshooting/	Debugging a defect; scientific method, rubber ducking, reproduce-as-test, bisection, non-deterministic defects
references/security/	Threat modelling; STRIDE (spoofing, tampering, repudiation, info disclosure, DoS, elevation)
references/code-navigation/	Onboarding to a code base; big picture, file organisation, cycles, property-based testing, behavioural code analysis
references/practices-glossary/	Looking up a named practice by name (28 entries: 50/72, 80/24, AAA, Bisection, CQS, Strangler, etc.)

⚠️ Editorial amendments (NOT from the book)

The folder below is NOT content from Seemann's book. It contains our own additions covering agent-specific concerns the 2021 book does not address. Do not attribute these files to Seemann. See references/agent-native/knowledge.md.

Topic	Use when...
references/agent-native/	The question is specifically about how a code agent should do something differently from Seemann's 2021 guidance — tight verification loops, hallucination debugging, strict types as primary guardrails, reviewable vs readable code

Workflows

Composite step-by-step processes live in workflows/:

Task	Workflow
Review a pull request / piece of code	workflows/review-code.md
Add a new feature from scratch	workflows/add-feature-outside-in.md
Investigate and fix a defect	workflows/debug-defect.md
Threat-model a new endpoint	workflows/threat-model.md

See guidelines.md for the full routing layer (task → file, symptom → file, decision tree).