Originally published on Maker.io (DigiKey).
The article opens with two implementations of the same function — one sprawling, one concise — and asks why the shorter one feels easier to work with, not just shorter. The answer leads to a “spectrum of badness” from “doesn’t work” through “barely working spaghetti” to “simple and correct,” with cyclomatic complexity and unnecessary abstraction as the two main drags on code quality.
The case study is a real function: parsing GCC .d dependency files to extract a list of file paths. The first solution had a subtle bug (mutating a list while iterating over it), and fixing it revealed a simpler framing of the whole problem — read the file as one string, replace newlines with spaces, split on spaces, filter for valid paths. The result is shorter, has no mutation hazard, and is easier to reason about.
When a simple solution isn’t available, structured refactorings (Extract Method, Replace Conditional with a Look-up Table) keep complexity manageable. When complexity is unavoidable, comments that show concrete input/output examples and accompanying flowcharts are more useful than prose descriptions — and a unit test is worth more than either.