"impediment to action advances action. what stands in the way, becomes the way".

I don't think it holds in 100% of situations but I do think if you're going to make an error one way or the other, I'd rather do something smaller and release too early than do something bigger and waste time.

It's in a field that I have little experience with (Information Retrieval). So there is obviously prior art that I could learn from or even integrate with.

This article motivates me further to learn things by focusing on building my own and peek into prior art as I go, when I'm stuck or need ideas.

Recently a Clojure documentary came out and the approach of Rich Hickey was seemingly the opposite: Deep research of prior art, papers, other languages over a long period of time.

However, he also mentioned that he made other languages before. So the larger story starts earlier, by making things and learning from practice.

Maybe that's also the bigger lesson: Don't overthink, start by making the thing. But later when you learned a bunch of practical lessons and maybe hit a wall or two, then you might need that deeper research to push further.

Sometimes you just want to button-mash through, rushing about carefree.

Other times, you want to go entirely stealth, wandering around, trying to find the best path, wasting an hour or more on a level you could have button-mashed in 5 minutes.

Both are fine.

See also "Why does the C++ standard ship every three years" (as opposed to ship when the desired features are ready):

https://news.ycombinator.com/item?id=20428703 (2019-07-13, 220 comments)

Great explanation for what I see when I mess around with coding LLMs. The natural human instinct of “this feels complicated, let me think about it some more” is suppressed. So far all the gains from the stunning initial speed have been cancelled out later in the project, arising from the over-engineered complexity baked into the code.

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 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.

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.

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.

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.

Maybe I lack imagination or curiosity, but it makes it difficult to come up with an idea and follow it through.

Prototype a minority of the time. Research a majority of the time. At some point the ratio flips as research fades out and producing increases.

Organizations and Conferences:

1. Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.

2. Make “speeches,” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of personal experiences.

3. When possible refer all matters to committees, for “further study and consideration”. Attempt to make the committees as large as possible – never less than five.

4. Bring up irrelevant issues as frequently as possible.

5. Haggle over precise wordings of communications, minutes, resolutions.

6. Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.

7. Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.

8. Be worried about the propriety of any decision – raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.

Managers and Supervisors:

1. Demand written orders.

2. “Misunderstand” orders. Ask endless questions or engage in long correspondence about such orders. Quibble over them when you can.

3. Do everything possible to delay the delivery of orders. Even though parts of the order may be ready beforehand, don’t deliver it until its completely ready.

4. Don’t order new working materials until your current stocks have been virtually exhausted, so that the slightest delay in filling your order will mean a shutdown.

5. Order high-quality materials which are hard to get. If you don’t get them argue about it. Warn that inferior materials will mean inferior work.

6. In making work assignments, always sing out the unimportant jobs first. See that important jobs are assigned to inefficient workers with poor equipment.

7. Insist on perfect work in relatively unimportant products send back for refinishing those which have the least flaws. Approve other defective parts whose flaws are not visible to the naked eye.

8. Make mistakes in routing so that parts and materials will be sent to the wrong place in the plant.

9. When training new workers, give incomplete or misleading instructions.

10. To lower moral and with it production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work.

11. Hold meetings when there is critical work to be done.

12. Multiply paperwork in plausible ways. Start duplicating files.

13. Multiply the procedures and clearances involved in issuing instructions, making payments, and so on. See that three people have to approve everything where one would do.

14. Apply all regulations to the last letter.

This technique is called out in the CIA simple field sabotage manual.

do you want to learn a new skill? do you want to scratch a very specific personal itch for just yourself? do you want to solve problems for others as well? do you want to build a startup/business around the idea?

all of these necessitate different approaches and strategies to research and coding. scratching an itch? maybe fully vibe coding is fine. want to learn? ditch the vibes and write by hand and ignore prior art. want to build a business? do some actual market research first and decide if this is something you actually want to pursue.

this post was a good reminder for me to identify the why as early on as possible and to be ok with just building something for myself without always having to monetize a side project which, for me, just zaps all joy from it.

Project where the sole user is you in your kitchen? Sure, hack it together.

Project where you actually want other people to use the product? A research phase matters and helps here.

Consider what the goal is and the amount of effort to invest typically becomes more evident.

Basically, you will end up dependent on the massive complexity of a compiler due to the syntax complexity, and the cherry on top, thanks to ISO, you'll get feature creep creating a cycle of planned obsolescence around 5 to 10 years.

Oh, sorry, "they" called that "innovation".