Just Build the Shelf: Avoiding the Trap of Overthinking

Kevin Lynagh discusses how over-researching prior art and fuzzy success criteria can lead to project paralysis and unnecessary scope creep. He observes that while LLMs increase coding speed, they often tempt developers to add features they don't actually need. To combat this, he advocates for a 'just do it' approach, focusing on building a minimal, entity-based diffing tool for his personal Emacs workflow.

Key Points

• Internalizing specific success criteria is the most important factor in avoiding project paralysis and overthinking.
• Researching 'prior art' can be a trap that leads to incorporating unnecessary scope and losing the joy of creation.
• The 'conservation of scope creep' suggests that increases in programming speed (via LLMs) are often offset by the addition of useless features.
• Existing structural diffing tools often fail to match code entities correctly or are too complex for simple, personal workflows.
• Prioritizing 'doing' over 'considering' leads to more productive learning and tangible results, even if the output is imperfect.

Sentiment

The community overwhelmingly agrees with the article's core message. Commenters enthusiastically share personal experiences confirming that overthinking and scope creep are universal project killers. The LLM scope creep conservation idea generates particularly strong resonance. Mild pushback comes from those who value research phases and note that the right amount of planning depends on context, but these are minority voices offering nuance rather than fundamental disagreement.

In Agreement

• PhD research suffers from the same pattern: exhaustive literature reviews drain energy before the real work begins, and keeping scope tiny is the key to finishing
• The 'conservation of scope creep' law rings true — LLM coding speed gains are fully absorbed by implementing unnecessary features and rabbit holes
• Projects fail not from lack of ideas but from never converging; locking scope early and shipping v1 is what separates finishers from dreamers
• Overthinking feels like productive work but produces no output — switching from 'is this the right architecture' to 'is this the next correct change' is transformative
• The CIA Simple Sabotage Field Manual describes exactly these patterns — requiring exhaustive research, committee review, and perfect solutions is a known sabotage technique
• The scope creep cure pre-LLM was fatigue; now that fatigue takes longer to kick in, the cure has to be cognitive and intentional

Opposed

• Research phases genuinely matter for products intended for other users — just hacking something together only works when you're the sole user
• Domain knowledge determines the right approach: if you know the domain well, extensive upfront planning saves significant rework later
• Sometimes scope creep reveals the real problem you're solving, and the expanded scope becomes the actual valuable project
• Rich Hickey's approach with Clojure was the opposite — deep research of prior art over a long period — and it produced an excellent result
• The article itself is criticized for being unfocused and exhibiting scope creep by diving into structural diffing after discussing overthinking