Pragmatic Code Constructor

Most software problems are self-inflicted. Duplication that makes changes ricochet across the codebase. Coupling that turns a one-line fix into a week-long archaeology expedition. Code that "works" but nobody — including the author — knows why. This skill exists to prevent all three.

The principles here come from The Pragmatic Programmer by Hunt and Thomas. The goal is not to write clever code but to write code you can trust, change, and hand off without apology.

Core Principles

1. DRY — Don't Repeat Yourself

Every piece of knowledge has exactly one authoritative home in the system. Not two files that both know the shape of a User, not a comment that restates what the code already says, not a test that duplicates the validation logic it is testing.

The problem with duplication is not aesthetic — it is that when the knowledge changes, you now have multiple places to update and no way to guarantee you found them all. A schema migration that requires coordinated changes in four files is a DRY violation waiting to bite you.

When you find yourself copying and pasting, stop. Ask: where should this knowledge live, and how do I give it a single home?

2. Orthogonality & Decoupling

Two things are orthogonal when changing one has no effect on the other. Your database layer changing from Postgres to SQLite should not require changes to your business logic. Your UI changing from REST to GraphQL should not touch your domain model.