reducing-entropy

Topics in the source

• Reducing Entropy
• Before You Begin
• The Goal
• Three Questions
• 1. What's the smallest codebase that solves this?
• 2. Does the proposed change result in less total code?
• 3. What can we delete?
• Red Flags

More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase. Core question: "What does the codebase look like after?" Load at least one mindset from references/ 1. List the files in the reference directory 2. Read frontmatter descriptions to pick which applies 3. Load at least one 4. State which you loaded and its core principle Do not proceed until you've done this. The goal is less total code in the final codebase - not less code to write right now. Writing 50 lines that delete 200 lines = net win Keeping 14 functions to avoid writing 2 = net loss "No churn" is not a goal. Less code is the goal. Measure the end state, not the effort. 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? Count lines before and after. If after > before, reject it. "Better organized" but more code = more entropy "More flexible" but more code = more entropy "Cleaner separation" but more code = more entropy Every change is an opportunity to delete. Ask: What does this make obsolete? What was only needed because of what we're

This is an excerpt. Refer to the complete source and its current requirements.