静かな裏で破壊される：なぜ私の大多数のプロジェクトが「過剰思考」で消えてしまったか

ケヴィン・リンエイグは、この週に自らのプロジェクトを「過剰思考」「スコープクリープ」「構造的差分（structural diffing）」によって sabotage（破壊）し、プロジェクトを殺しているというエッセイを発表した。必要な Emacs のショートカットを探すために、4 時間もセマンティックな差分ツールを調べる。Clown-Rust 組み込みの CAD ツールの制約に基づいた研究に数百時間も費やし、どちらも製品化されていない。このエッセイは私に強烈な響きを及ぼし、私がプロジェクトリストを維持していたからだ。 私のリストには、製品化せずに消したプロジェクトの名前が載っている。過去 3 年で、このリストは約 40 つに増えた。同じ期間で製品化（shipped）したのは 20 つ。つまり、1 つ製品化するために 2 つを殺している。 消されたプロジェクトのパターンはほぼ同一である。市場が殺しなかった。競合が殺しなかった。私がそのプロジェクトを構築する前に「過剰思考」によって消したのだ。 すべての死んだプロジェクトには、私のノートにある「研究の墓地」がある。ニッチなアーキテクチャ選択に関する深く読み込んだレポート。実際に使うことがないライブラリのベンチマーク。状態管理パターンの比較表。それらはすべて、私が欲しいものを作る最初の一行も書かないうちに収集された。 深さはいつも比例していない。UI フローを引く前に Rust async ランタイムの 4 ライヤープースに浸かった。ユーザーがベクトル検索を必要としているかどうかを知る前に、3 つのベクトルデータベースの遅延トレードオフを知り尽くした。研究は生産的に見える。ノートが埋まるからだ。しかし、それは actually（実際には）スマートな帽子で procrastination（遅延）である。 信号（tell）：何かの最も小さな製品化可能なバージョンよりも、より多くの時間を研究に費やした場合、あなたは研究していない。あなたはコミット（決断）を回避しているだけだ。 ケヴィンのエッセイはこれを直接的に名指した。彼は、棚（shelf）を設計するための CAD アプリを作るために、ある意味で道具として使われるはずだったプログラミング言語に対して数百時間も費やした。棚は決して組み立てられなかった。 私は常に这样做する。最近の例：あるツールに単純な分析ビューを追加したかった。計画を終えるまでに、「自分専用」の Plausible 代替品を構築する方法についての論文を書いてしまったのだ。私が運営している他の 13 つのプロダクトのために SaaS 分析サービスを支払いたくないからだ。スコープは「過去 30 日分の棒グラフ」から「OSS 分析プラットフォーム」に広げた。棒グラフは組み立てられなかった。OSS プラットフォームも組み立てられなかった。 製品化前（mile one）にスコープがクリープすると、元のニーズは引き離されて（orphaned）消えていく。引き離されたものは静かに死んでいく。新しいスコープは単一の週末ではやりすぎるほど野望に富み、すでに你有份の一日の仕事があるからだ。 これは最も微妙なケースだ。プロジェクトを開始しようとしている。エディターを開く。エディターの設定が少し間違ったように感じる。土曜日を新しい dotfiles 設定に費やした。設定には新しいターミナルを含む。新しいターミントはあなたのフォントを正しくレンダリングしない。あなたのフォントレンダリングパイプラインを再構築した。日曜日の夜には、プロジェクトの一行も書かなければならない。しかし、美しいターミナルがある。 ヤクシャベ（Yak-shave：不毛の労働）は実際の仕事に隣接したように見える。それはツールだからである。ツールは生産的だ。しかし、ツールが可能にするものさえ進行している場合のみ、生産的だ。 私は「健全性チェック」を実行するように学んだ。私が最初に始めたタスクがプロジェクトそのものではなく、かつ、次 1 時間以内にプロジェクトを直接ブロックしない場合は、タブを閉じる。 私たちが製品化したすべてのプロジェクトは同じ形状をたどった。それは「慎重に計画した」ではない。「徹底的に研究した」ではない。形状は以下の通りである： | ステップ | 出来事 | 時間 | |---|---|---| | 1 | 最も小さく有用なものを書いた | 1 ウォーク | | 2 | 誰かが使うかもしれない 1 人の前に置いてみた | 1 エヴニング | | 3 | 実際に必要なものを修正し、自分 thought していたものを修正しなかった | 1 ウォーク | | 4 | 公開して v0.1 をリリースした | 1 午後 | | 5 | 実際の利用に基づいてイテレーションを始めた | 継続中 | このすべては準備調査を必要としない。それは小さな楔（wedge）を選ぶことと、最初のバージョンが予測できない方法で間違っていることを受け入れることである。 私が別のタブで研究を開くよう自分自身を捕まえるとき、私は尋ねる：少し性能の悪いツールでは、この進捗を進めることができるか？ 我々は必須にセマンティックに正しい差分ツールを必要とするか、それとも git diff を使って進捗を得ることはできるか？ ベクトルデータベースを必要とするか、または最初の 1,000 つのために SQLite フルテキスト検索をどうすればよい？

Kevin Lynagh published a short essay this week about how he sabotages his own projects by overthinking, scope creep, and structural diffing. Four hours researching semantic diff tools when he needed an Emacs shortcut. Hundreds of hours on background research for a Clojure-Rust hybrid and a constraint-based CAD tool, neither shipped. The piece landed on me hard because I have been keeping a list. My list is of projects I killed without shipping. Over the last three years it has grown to about forty. In the same window I shipped twenty. So for every one I ship I kill two. The patterns of the killed ones are almost always the same. Market did not kill them. Competition did not kill them. I killed them by thinking too hard before building. Every dead project has a research graveyard in my notes. Deep reads on niche architecture choices. Benchmarks of libraries I would never actually use. Comparison tables of state management patterns. All of it collected before I had written a single line of the thing I wanted to build. The depth is always disproportionate. I am four layers into a Rust async runtime before I have drawn the UI flow. I know the latency tradeoffs of three vector databases before I know if my users need vector search at all. The research feels productive because the notes fill up. The research is actually procrastination in a smart hat. The tell: if you have spent more time on research than on the smallest shippable version of the thing, you are not researching. You are avoiding commitment. Kevin's essay names this directly. He spent hundreds of hours on a programming language that was meant to be a tool to build a CAD app that was meant to design a shelf. The shelf never got built. I do this constantly. A recent example: I wanted to add a simple analytics view to one of my tools. By the time I finished "planning," I had a writeup of how to build a self-hosted Plausible alternative because I did not want to pay for SaaS analytics for the other thirteen products I run. The scope went from "bar chart of last 30 days" to "OSS analytics platform." The bar chart never got built. The OSS analytics platform also never got built. When the scope creeps before you have mile one in production, the original need gets orphaned. The orphan dies quietly because the new scope is now too ambitious for a single weekend, and you already have a day job. This is the subtle one. You are about to start the project. You open your editor. The editor setup feels slightly wrong. You spend a Saturday on a new dotfiles config. The config involves a new terminal. The new terminal does not render your font correctly. You rebuild your font-rendering pipeline. By Sunday night you have not written a line of the project and you have a beautiful terminal. The yak-shave feels adjacent to real work because it involves tools, and tools are productive. They are only productive if the thing they enable is also happening. I have learned to run a sanity check: if the task I just started is not the project, and does not directly unblock the project within the next hour, I close the tab. Every project I have shipped followed the same shape. Not "planned carefully." Not "researched thoroughly." The shape is: Step What happened Time 1 Wrote the smallest useful thing 1 weekend 2 Put it in front of one person who might use it 1 evening 3 Fixed the thing they actually needed fixed, not the thing I thought they needed fixed 1 weekend 4 Released a v0.1 publicly 1 afternoon 5 Started iterating based on real usage ongoing None of this requires prep research. It requires picking a small wedge and accepting that the first version will be wrong in ways you cannot predict. When I catch myself about to open another tab for research, I ask: can I make progress on this with a slightly worse tool? Do I need the semantically-correct diff tool, or can I use git diff and move on? Do I need a vector database, or can I use SQLite full-text search for the first 1,000 users? Do I need a real design system, or can I use Tailwind defaults and ship? The answer is almost always yes. The worse tool is almost always enough. The time saved goes into actual product. I stopped asking "what is the right way to do this." I started asking "what is the smallest thing I can ship that would embarrass me in a useful way." The embarrassment is the signal. If v0.1 makes you flinch when users see it, that flinch will tell you what to build next. If v0.1 is polished, you have over-scoped and you will not learn what actually matters. My most successful products all embarrassed me at launch. theSVG shipped with 400 icons when the category leader had 10,000. Stacklit shipped with a single compression algorithm when more sophisticated approaches existed. Glin-Profanity shipped for one language. Every one of them got where they are because the first version landed and users told me what to fix. Looking at my graveyard, the top regret is not the projects I started and did not finish. It is the projects I kept alive for eight months of quiet background worry before admitting they were dead. Each of those eight-month zombies cost me a weekend per month in research and note-taking, while producing nothing. If you have been working on something for more than sixty days without a shipped version anyone has touched, you are probably not going to finish. Kill it. The grief is shorter than the slow bleed. The reason overthinking sabotages projects is not that thinking is bad. Thinking is fine. Thinking without a deadline is the problem. Without a shipping date, every new piece of information looks like it might matter, and the project drowns in adjacency. Kevin's shelf project worked because he gave it a weekend. Mine work when I give them one too. When I do not, they join the graveyard. Build the small thing. Ship the bad thing. Let users tell you what the good thing is. Do you have a graveyard? What killed the projects you did not ship? Comments open.