The Canon

Patterns

Repeating solutions from the masters. How "less, but better" manifests across domains.

Patterns to Embrace

Constraint as Liberation

Limitation breeds creativity. Rams' 10 principles. Mies' steel and glass. The Eameses' plywood.

✓ Limited color palette

✓ Restricted component library

✓ Fixed grid system

Functional Transparency

How something works should be evident. No mystery. No magic. Honest materials, honest code.

✓ Exposed structure (like Eames chairs)

✓ Self-documenting APIs

✓ Clear dependency graphs

Iterative Reduction

Start complex, remove relentlessly. Rams revised his designs dozens of times. So should you.

✓ Ship, measure, simplify

✓ Kill features based on usage

✓ Refactor toward clarity

Universal Utility

The Eameses' "the best for the most for the least." Tools should serve everyone without compromise.

✓ Accessibility by default

✓ Progressive enhancement

✓ Zero-config options

Timeless Materials

Choose what ages well. Avoid trends. Mies used steel because it endures. What's the steel of software?

✓ Web standards over frameworks

✓ SQL over NoSQL (for most cases)

✓ HTTP over proprietary protocols

Negative Space

What you don't build matters as much as what you do. Whitespace in design. Silence in music. Restraint in code.

✓ Generous margins and padding

✓ Sparse UI with clear hierarchy

✓ Functions that do one thing

Tool Complementarity

Tools should not compete for the same ontological space. Each has a domain. Heidegger's Zuhandenheit—ready-to-hand tools recede from consciousness.

✓ Clear boundaries between tools

✓ Handoff protocols, not redundancy

✓ Creation vs. operation domains

Dwelling in Tools

Build habits that make tools transparent. A carpenter forgets the hammer exists. Infrastructure should be invisible.

✓ Workflows that become automatic

✓ Configuration once, use forever

✓ Minimize conspicuousness, obtrusiveness, obstinacy

Principled Defaults

Every configuration value traces to a principle. Arbitrary numbers are decoration in disguise. 20px padding? Why 20?

✓ Spacing from golden ratio (1.618rem)

✓ Colors from functional meaning, not trends

✓ Typography from readability research

Reference Implementation

How patterns combine in practice. A terminal configuration applying hermeneutic analysis.

Terminal as Dwelling

WezTerm + Shell Configuration

Patterns applied: 5

Elements removed: 2

Values derived: 4

Derived from Canon

font_size 15pt ← canonical body (16-20px)
line_height 1.5 ← canonical body (1.5-1.6)
padding 26px ← golden ratio (--space-md)
colors muted ← functional, not iOS

Removed (Failed Justification)

Claude launcher feature creep
Resize keybindings system conflict

Patterns Demonstrated

Dwelling in Tools Principled Defaults Iterative Reduction Constraint as Liberation Functional Transparency

Hermeneutic Verification

Part → Whole: Does this config reveal the CREATE SOMETHING ethos? Yes—black/white palette, mathematical spacing, no decoration.

Whole → Part: Can every value trace to canon? Yes—typography, spacing, colors all derive from .ltd standards.

Circle Closes: The tool recedes. The user dwells. Zuhandenheit achieved.

Anti-Patterns to Avoid

Feature Creep

Adding features because you can, not because users need them. Every addition requires justification.

Instead: Start with core functionality. Add only what proves necessary.

Decorative Complexity

Ornamentation that serves ego, not users. Animations without purpose. Gradients for "visual interest."

Instead: Every visual element must communicate or assist. Otherwise, remove it.

Trend Chasing

Adopting the latest framework, design style, or methodology because it's popular. This ages poorly.

Instead: Choose based on fundamental principles. Trends fade. Standards endure.

Premature Abstraction

Building for hypothetical future use cases. Creating frameworks before you have two examples.

Instead: Wait for the pattern to emerge three times. Then abstract.

Metric Vanity

Optimizing for engagement, clicks, or growth over utility. Users as numbers instead of people.

Instead: Measure what matters. Completion rates. Error reduction. Time saved.

Dishonest Documentation

Hiding limitations. Cherry-picking results. Marketing copy disguised as research.

Instead: Document failures alongside successes. Honest metrics. Transparent methodology.

Tool Redundancy

Multiple tools competing for the same task. Confusion about which to use. Duplicated capabilities without differentiation.

Instead: Assign clear domains. Define handoff protocols. Eliminate overlap.

Recognizing Patterns in Your Work

The masters didn't invent these patterns—they discovered them through decades of practice. You'll find them too.

When you remove a feature and the product gets better, that's Iterative Reduction.

When constraints force you to solve a problem elegantly, that's Constraint as Liberation.

When code needs no comments because the structure is self-evident, that's Functional Transparency.

When you stop asking "which tool should I use?" because each has a clear domain, that's Tool Complementarity.

"The ability to simplify means to eliminate the unnecessary so that the necessary may speak."

— Hans Hofmann