What is Creation?
Introduction
Most of us think of creation as addition. We add features to software. We add elements to designs. We add capabilities to systems. The more we add, the more creative we must be—or so the story goes.
But this is backwards.
Creation is the discipline of removing what obscures.
Like Michelangelo freeing David from marble, we don't add the statue—we remove everything that isn't the statue. The truth was always there, buried under excess.
The Addiction to Addition
Why do we default to addition?
Effort is visible. When we add something, we can point to it. "I built this feature." "I designed this component." Addition creates artifacts we can showcase.
Subtraction is invisible. When we remove something, the work disappears. What remains looks obvious in hindsight. "Of course it should be this simple." The discipline that created the simplicity vanishes with the complexity.
This asymmetry makes addition feel safer. But addition without discipline creates:
- Code bloat → Duplicated logic, inconsistent patterns
- Feature creep → Interfaces that do everything, master nothing
- System fragmentation → Components that don't compose, services that don't connect
We keep building, but the creation becomes harder to see.
The Subtractive Turn
Subtraction requires a different question. Not "What can I add?" but "What is already here?"
Truth doesn't need to be created. Truth needs to be revealed.
- The interface already knows what it wants to be—remove the excess chrome
- The code already knows its pattern—remove the duplication
- The system already knows its structure—remove the disconnections
Creation is archeology, not invention.
The Three Levels
Every creation exists simultaneously at three scales, each requiring its own subtractive discipline:
| Level | Scale | Question | Discipline |
|---|---|---|---|
| Implementation | Code, logic, algorithms | "Have I built this before?" | DRY → Unify |
| Artifact | Features, interfaces, components | "Does this earn its existence?" | Rams → Remove |
| System | Services, properties, platforms | "Does this serve the whole?" | Heidegger → Reconnect |
These aren't separate philosophies—they're one principle (subtractive revelation) applied at three scales.
Implementation: DRY
At the lowest level, we eliminate duplication. When you've written the same logic twice, truth is obscured by repetition. Extract, unify, clarify.
Example: Three functions that validate email addresses differently. The truth (what makes an email valid?) is scattered across implementations. Unify them into one source of truth.
Artifact: Rams
At the artifact level, we eliminate excess. Every element must earn its existence. If it doesn't serve the user's need, it obscures what does.
Example: A form with 15 fields when 5 would suffice. The extra fields don't add capability—they obscure the essential questions. Remove them.
System: Heidegger
At the system level, we eliminate disconnection. Every part must serve the whole. When services don't compose or properties don't connect, the system fragments.
Example: Three microservices that duplicate authentication logic because they can't share a session store. The disconnection creates duplication. Reconnect them.
Why This Works
The Subtractive Triad is coherent because it's one principle at three scales.
You're not learning three separate philosophies. You're learning one way of seeing—subtractive revelation—applied to every level of your work.
- DRY reveals truth by removing implementation duplication
- Rams reveals truth by removing artifact excess
- Heidegger reveals truth by removing system disconnection
The pattern is fractal. The same discipline works whether you're naming a variable or architecting a platform.
The Discipline
Subtraction is harder than addition. It requires:
- Seeing what's there → You can't remove duplication you don't notice
- Judging what's essential → You can't remove excess without criteria
- Tracing connections → You can't remove disconnections without understanding the whole
This is why creation is a discipline, not a talent. You develop the eye through practice:
- Read code until you see patterns
- Study designs until you feel excess
- Map systems until you trace the threads
The work is training your perception.
What You'll Learn
In the lessons ahead, you'll develop each level:
- DRY → Recognizing and unifying duplication
- Rams → Judging what earns its existence (Weniger, aber besser)
- Heidegger → Understanding systems through the hermeneutic circle
- Application → Using all three levels together
By the end, you won't just know the Subtractive Triad—you'll see through it. The questions will become automatic:
- Have I built this before? → DRY
- Does this earn its existence? → Rams
- Does this serve the whole? → Heidegger
Creation will become the discipline of removing what obscures.
Cross-Property References
Canon Reference: See The Subtractive Triad for the canonical statement of these principles.
Research Depth: Read Hermeneutic Spiral in UX for how subtractive thinking applies to user experience design.
Practice: Try the Triad Audit experiment to apply DRY → Rams → Heidegger to real code.
Reflection
Before moving on, consider:
- What's the last feature you added to a project? Could it have been revealed by removing something instead?
- Where do you see duplication in your current work—at the implementation, artifact, or system level?
- Why does addition feel safer than subtraction in your practice?
The answers don't matter as much as the habit of asking. This is the beginning of subtractive sight.