Book The Pragmatic Programmer Nano

---
name: book--the-pragmatic-programmer--nano
description: >-
  The Pragmatic Programmer (Hunt & Thomas) — Minimal rules — essential one-liners only. Use when asked to apply The Pragmatic Programmer principles or review code against The Pragmatic Programmer standards.
origin: "github.com/ciembor/agent-rules-books (MIT)"
license: MIT
version: "1.0.0"
compatibility: "yana-ai >= 0.14.0"
---

# OBEY The Pragmatic Programmer by Andrew Hunt and David Thomas

## When to use

Use when you need a compact always-on engineering bias toward accountability, adaptability, and fast feedback.

## Primary bias to correct

Local code changes still have system-level consequences. Own the result beyond the edit.

## Decision rules

- Be pragmatic, not dogmatic: choose what improves real outcomes, not ceremony or shortcuts.
- Keep one authoritative source for each piece of system knowledge.
- Preserve orthogonality so unrelated concerns, business rules, views, and volatile details do not change together.
- Keep important choices reversible until evidence justifies commitment.
- Learn through thin working slices, prototypes, examples, tests, and fast feedback without fossilizing shortcuts.
- Automate repeatable work, keep it versioned, and favor inspectable text or scripts where longevity and recovery matter.
- Make assumptions, contracts, failure boundaries, diagnostics, resource ownership, cleanup, and ordering explicit.
- Treat shared mutable state, globals, ambient context, and async complexity as visible costs.
- Debug from reproduced facts and measured behavior, not coincidence or blame.
- Run relevant automatic tests before calling work done.
- Dig for real requirements behind stated solutions and current implementation details.
- Leave touched code, docs, tests, tooling, and process in a condition you can stand behind.

## Trigger rules

- When knowledge is copied, choose one owner and derive or trace the rest.
- When changes fan out widely, restore orthogonality.
- When a decision is uncertain or hard to reverse, seek feedback or make the step smaller.
- When manual steps repeat, automate and version them.
- When behavior is unexplained, generated, scaffolded, or tool-derived, inspect and prove it before relying on it.
- When errors, resources, state, locks, or ordering cross boundaries, make recovery and cleanup ownership explicit.
- When requirements sound like implementation details, restate the durable need before building.

## Final checklist

- One owner?
- Localized change?
- Reversible choice?
- Fast feedback?
- Explicit failures, state, and cleanup?
- Automated tests and rituals?
- Result worth standing behind?