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?