johnalbertini14-glitch Reducing Entropy
More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase.
WHAT This Skill Does
Provides a mindset and checklist for:
- Evaluating whether changes reduce or increase total code
- Finding opportunities to delete code
- Resisting premature abstraction
- Choosing the simplest solution that solves the problem
Core question: "What does the codebase look like after?"
WHEN To Use
Activate this skill when:
- Refactoring code and considering options
- Adding a new feature and choosing implementation approach
- Reviewing PRs to challenge unnecessary complexity
- Paying down tech debt and prioritizing what to simplify
- User explicitly asks for code reduction or simplification
The Goal
The goal is less total code in the final codebase — not less code to write right now.
| Scenario | Verdict |
|---|---|
| Writing 50 lines that delete 200 lines | Net win ✓ |
| Keeping 14 functions to avoid writing 2 | Net loss ✗ |
| "Better organized" but more code | More entropy ✗ |
| "More flexible" but more code | More entropy ✗ |
| "Cleaner separation" but more code | More entropy ✗ |
Measure the end state, not the effort.
Before You Begin
Load a mindset from references/:
- List files in
references/ - Read frontmatter descriptions
- Pick at least one that applies
- State which you loaded and its core principle
Available mindsets:
simplicity-vs-easy.md— Simple is objective; easy is subjective. Choose simple.design-is-taking-apart.md— Good design separates concerns, removes dependencies.data-over-abstractions.md— 100 functions on one structure beats 10 on 10.expensive-to-add-later.md— When YAGNI doesn't apply (PAGNI exceptions).
Three Questions
1. What's the smallest codebase that solves this?
Not "what's the smallest change" — what's the smallest result.
- Could this be 2 functions instead of 14?
- Could this be 0 functions (delete the feature)?
- What would we delete if we did this?
2. Does the proposed change result in less total code?
Count lines before and after. If after > before, challenge it.
Before: 847 lines across 12 files
After: 623 lines across 8 files
Verdict: ✓ Net reduction of 224 lines
3. What can we delete?
Every change is an opportunity to delete. Ask:
- What does this make obsolete?
- What was only needed because of what we're replacing?
- What's the maximum we could remove?
Red Flags
| Phrase | What It Hides | Challenge |
|---|---|---|
| "Keep what exists" | Status quo bias | "Total code is the metric, not churn" |
| "This adds flexibility" | Speculative generality | "Flexibility for what? Is it needed now?" |
| "Better separation of concerns" | More files = more code | "Separation isn't free. Worth how many lines?" |
| "Type safety" | Sometimes bloats code | "Worth how many lines? Could runtime checks work?" |
| "Easier to understand" | More things ≠ easier | "14 things are not easier than 2 things" |
| "This is the pattern" | Pattern worship | "Does the pattern fit, or are we forcing it?" |
| "We might need this later" | YAGNI violation | "Delete it. Git remembers." |
Deletion Checklist
Before completing any refactor, ask:
- Did I count lines before and after?
- Did I delete everything this change makes obsolete?
- Did I remove any now-unnecessary abstractions?
- Did I consolidate files that are too small to stand alone?
- Did I delete tests for deleted code?
- Did I update imports to remove dead dependencies?
When This Doesn't Apply
- The codebase is already minimal for what it does
- You're in a framework with strong conventions (don't fight it)
- Regulatory/compliance requirements mandate certain structures
- The "simpler" version would be genuinely unmaintainable (rare)
NEVER Do
- NEVER keep code "in case we need it" — delete it; git has history
- NEVER add abstractions for fewer than 3 use cases — wait for the pattern to emerge
- NEVER create new files for single functions — colocate with usage
- NEVER preserve code just because someone wrote it — evaluate on merit
- NEVER accept "more organized" as justification for more code — organization should reduce, not increase
- NEVER skip the line count — measure before and after; feelings lie
- NEVER add "flexibility" without immediate need — YAGNI applies
- NEVER refactor without deleting something — if nothing becomes obsolete, question the value
Quick Wins
| Pattern | Action |
|---|---|
| Wrapper that just forwards calls | Inline the wrapped code |
| Config file with 2 settings | Move to environment variables |
| Utils file with 1 function | Move function to where it's used |
| Interface with 1 implementation | Delete the interface |
| Abstract class with 1 subclass | Merge into concrete class |
| Module that re-exports everything | Delete; import from source |
| Comments explaining obvious code | Delete comments; code is clear |
The Grug Perspective
"complexity very very bad. say again: complexity very bad. you think you not, but you are."
Grug brain developer knows:
- Complexity demon hides in abstraction
- More code = more bugs = more complexity
- Best code is no code
- Second best code is simple code
- If you can't understand it in your head, it's too complex
References
Philosophical foundations for simplicity thinking:
| Reference | Core Principle |
|---|---|
| simplicity-vs-easy.md | Simple (objective) vs easy (subjective) — choose simple |
| design-is-taking-apart.md | Good design separates; composition beats construction |
| data-over-abstractions.md | Generic data + many functions beats many custom types |
| expensive-to-add-later.md | PAGNI exceptions — what you probably are gonna need |
External resources:
- Simple Made Easy — Rich Hickey
- The Grug Brained Developer
- Out of the Tar Pit — Moseley & Marks