For someone who says they are overcome by scope creep, they sure do seem to get a lot done — so many linked articles on all sorts of topics at the end of the post.

I think the author is indeed someone who just really enjoys learning and doing all sorts of things, so the rabbitholing is part of the fun that tickles their brain.

Over planning and scope creep are a problem, but let's not swing the pendulum to far the other way. Some of my most successful projects were projects where I planned out and worked through most of the features ahead of time through the process of modeling my data without any working software to try out. When I'm in that phase, I often don't really know what is too much. If I leave out features I think I or the users will probably want, I spend a lot of time with significant redesign of core aspects of the code. If I'm wrong, the project gets too big and we chalk it up to scope creep.

My ability to get this right is often a matter of how well I know the domain. If I don't know the domain as well I think I do, I fall into a lot of rework. If I know the domain more than I imagine then I waste my time with a baby step process when I could have run. All of this is a big judgement call, and I have "regrets" in both directions.

I am a solo builder and one thing that helped me a lot was this: most of what looks like a "necessary abstraction" is actually scope creep with a different name. I was adding a flag for every new feature and I noticed the pattern in my own code, so I made one rule: a feature can not land until its flag-off behavior has a test. That changed how I see flags. The flag is part of the product, not an escape hatch. Three features in my backlog died by themselves when I started thinking like this.

Firstly - Greetings! It’s so rare to see a Clojure person in the wild! and secondly, I really resonated with this! it feels like we, computer programmer, typically overthink too much to begin with, and then LLMs come along and actually help us overthink even more!

This is a pretty common failure mode in engineering too.

You start with a simple goal → then research → then keep expanding scope → and never ship.

The people who actually finish things do the opposite: lock scope early, ignore “better ideas”, ship v1.

Most projects don’t fail due to lack of ideas, they fail because they never converge.

Sounds like AI

Sabotage is intentional, but the problem is unintended excursions, which is endemic to any scouting.

The real problem is avoidance, when cuts are warranted and you don't want them, so you ... hide, often by working hard on something else.

The solution is to value your time. Most don't, so (self-) managers instead need to dangle other opportunities: finish this so you can do that. You can't take candy from a baby without trouble; instead, you trade for something else.

Difftastic can even diff plaintext by treating it as Elvish! https://stackoverflow.com/questions/49278577/how-to-improve-...

> Perhaps there’s some kind of conservation law here: Any increases in programming speed will be offset by a corresponding increase in unnecessary features, rabbit holes, and diversions.

This resonates hard. LLMs enable true perfectionism, the ability to completely fulfil your vision for a project. This lets you add many features without burning out due to fatigue or boredom. However (as the author points out), most projects' original goal does not require these complementary features.

The newest structural diff tool is RefactoringMiner, there's a paper and a Github repo that works out of the box which is rare for this space. Excellent results but mainline is limited to Java IIRC with a couple ports for other languages.