The Half-Life of an Idea: One Man's Inbox, Measured
The Pile That Looks Like Failure
There are 241 open items in the inbox. That number has been mentioned several times across this series, always in passing, always as background, and always with the same unspoken implication: that 241 is a lot, that a pile that size is evidence of something going wrong, and that the correct response is either guilt or a better tool.
This episode does something different with it. It asks the database what actually happens to an idea after it is captured. Not what it feels like happens. What the timestamps say.
The answer overturns the premise, and then it points at a real problem somewhere else entirely.
What The Numbers Say
Between the 23rd of February 2026 and the 30th of August, 1,660 items went into that inbox. Of those, 1,419 are closed. 241 are open.
That is a closure rate of roughly 85 percent.
Sit with that for a second, because it does not match the story anybody tells about their own capture system. The universal experience of keeping an idea inbox is that it is a place where thoughts go to be forgotten. It feels like a landfill. Everyone who keeps one describes it in roughly those terms, usually while apologising for it.
This one closes 6 items out of every 7.
Break it down by the month the item was created and the picture gets sharper. Of items captured in February, 93 percent are done. March, 90 percent. April, 92 percent. May, 94 percent. Then June, 83 percent. July, 73 percent. And August, the month still in progress as this is recorded, 67 percent.
That is not a system failing at different rates in different months. That is a single consistent process seen at different stages of completion. The older the month, the more of it is finished, and the curve is remarkably smooth.
The Half-Life
Which means the right way to describe this inbox is not as a queue with a backlog. It is a decay curve.
An item enters. There is some probability per unit time that it gets resolved. Early on that probability is high, because fresh items are attached to something currently happening. It falls off as the item ages and the context around it evaporates. And the population of open items at any moment is the residue of that process, weighted heavily toward the recent.
The measurement bears that out precisely. Of the 241 currently open, 161 were captured in the last 4 months, and 80 in the 3 months before that. And the oldest open item in the entire system dates from the 23rd of February. There is nothing older. Not one item from 2025 is still sitting there unresolved.
That is the most surprising finding in the whole exercise. Most people's idea piles have a sediment layer, a stratum of things captured years ago that nobody will ever look at again but nobody can quite bring themselves to delete. This one does not. The pile has a hard floor at about 6 months, which means that one way or another, everything either gets done or gets cleared within roughly half a year.
A half-life of a few months, with nothing surviving past 6. That is a working system with a healthy tail, not a graveyard.
What Is Actually In The Residue
Worth looking at what does survive to the bottom of that curve, because the survivors have a family resemblance.
The oldest open items, the ones from late February, include: a simplified English version of a company website. A launch plan for a podcast domain, with a trial run of the first 3 episodes in each series. A note that says, in full, app icons, web interface look and feel. A question about whether the version control strategy should use more branching. And a proposal that there should be a mobile application collecting all the weird things that have been built.
Look at what those have in common. Not one of them is a task. Every single one is a decision, or a direction, or an aesthetic. They are the items where the work is not "do this thing" but "decide what this should be", and deciding cannot be scheduled the way doing can.
That is why they survive the decay curve. The curve is killing tasks efficiently, because a task has a definition of done and an afternoon can close it. What accumulates at the bottom is the class of item that no afternoon can close, because the work is judgement rather than effort.
So the residue is not a list of failures. It is a fairly accurate list of the open questions in a business. Which is a completely different object, and probably ought to live somewhere other than an inbox, since an inbox implies that the correct end state is empty.
Where The Abandonment Actually Lives
If the inbox is healthy, the obvious next question is whether anything is not. And there is an answer, and it is not subtle.
There are 172 code repositories in the system. 24 are marked active. 141 are marked parked. 5 archived, 2 done.
82 percent of everything ever started is parked.
That is where the abandonment is. Not in the capture inbox, which is closing 85 percent of what enters it, but one layer down, in the things that got past the idea stage, got a repository, got a name, got some hours, and then stopped.
A parked repository is a much more expensive object than an unread note. A note costs a line in a database. A repository has dependencies that go stale, a security surface that ages, possibly a running service somewhere, possibly a domain, possibly a scheduled job still firing into a void. It represents real hours already spent, which makes it psychologically much harder to delete than a note ever was. Sunk cost attaches to code in a way it never attaches to a thought.
The honest reading is that the filter is in the wrong place. Ideas are being triaged rigorously. Projects are not being triaged at all, they are just being paused, and pause is not a decision. It is the absence of one.
Forty-Eight Projects In One Month
Then there is the working pattern itself, which the session log records in some detail.
In August, there were 307 recorded coding sessions across 48 distinct projects. In July, 390 sessions across 36. In May, 343 across 43.
Three hundred sessions a month is roughly 10 a day, every day, which is a considerable amount of work by any measure. The number that deserves attention is the other one. Forty-eight distinct projects touched in a single month, against 24 that are marked active. Meaning the month's attention went to twice as many things as are officially in flight.
There are 2 honest readings of that and both deserve airtime.
The unflattering one is dispersion. Six sessions per project per month is not enough to build momentum on anything substantial. Every return to a project costs reload time, and the reload cost is paid 48 times a month. That is the pattern that produces 141 parked repositories, because breadth at this width means most things get touched just often enough to stay alive and not often enough to finish.
The flattering one is that this is what running several businesses actually looks like, and it is not a defect. A newspaper, a rental company, and a consultancy do not produce work that can be batched into one deep focus block. Some of those 48 are 20-minute maintenance visits that keep something in production alive, and calling those a failure of focus would be like calling changing a lightbulb a failure of concentration. Breadth is also how the useful accidents happen, which is the same argument Hamming made about the open door: less efficient day to day, more likely to matter over years.
The data cannot settle which reading is right, and anyone claiming otherwise is selling something. What the data can do is put a number on the trade so it is being made knowingly.
The Unfinished Sentence
One last measurement, and it is the one that would be easiest to act on.
Of the 24 active repositories, 22 carry a recorded note about what to do next, written at the end of the last session. The average time since the last commit across those active projects is 10 days.
Twenty-two unfinished sentences, each one written by a person who at that moment knew exactly what the next move was, addressed to a future self who by now has forgotten.
That is a genuinely valuable asset and it is depreciating. A next-step note written 3 days ago is a running start. The same note at 10 days is a puzzle, because the reasoning behind it has evaporated and only the conclusion remains. At 30 days it is often actively misleading, because the situation has moved and the note has not.
Nothing in the system currently notices when one of those notes crosses from useful into stale. It just sits there looking equally authoritative on day 2 and day 90.
The Honest Reading
Put it together and the conclusion is close to the opposite of the one anyone would reach by looking at the inbox and feeling bad about it.
The capture system works. It closes 85 percent of what enters it, it has no sediment older than 6 months, and the residue it leaves behind is not junk, it is the set of genuine open questions that were never task-shaped to begin with. It does not need semantic search, a better interface, or a hardware button. It needs its residue moved somewhere that does not imply failure by existing.
The project layer does not work the same way, and 141 parked repositories against 24 active is the number that should be uncomfortable. Not because parking is wrong, but because nothing in the system ever asks whether a parked thing should be killed, and so the pile only grows in one direction.
And the highest-value small intervention is none of the projects that got sketched in this series. It is a date on a next-step note. Something that looks at those 22 sentences once a week and flags the ones that have gone cold, because a cold note is not a lead, it is a small piece of debt wearing a lead's clothing.
Three hundred sessions a month is not a productivity problem. Nobody working at that rate needs to be told to work harder. What the numbers actually describe is a person who is extremely good at closing things and has no mechanism at all for abandoning them, which are not the same skill, and only one of them was ever built.