My Drafts Folder Is a Graveyard, and a WIP Limit Fixed It, So Far
· 6 min read
Every idea for this blog starts the same way. I pin a note in Google Keep, or I scribble a line in the notebook that lives on my desk, and that’s it. There’s no next step after that. Nothing turns “idea” into “task.” It just sits there next to a dozen other notes until I forget why I wrote it down.
That gap is the problem, and it’s a lot like a parking lot with three spaces and noone to attend to it. A sign says the limit is three cars.
Nobody’s watching, so cars just don’t leave. I’ll come back to what happens once you hire the attendant.
What I end up is a drafts folder that only gets bigger. I went and counted it before writing this. I have 36 half-finished posts sitting in there since late June, spanning TypeScript, React, accessibility, build tooling, whatever I got excited about that week. Some are half finished, others just the title and not content.
Nine made it to the actual site in the same stretch. That’s most of my writing time disappearing into somewhere that isn’t the blog.
Contents
Where the mess actually starts
The drafts folder isn’t really the problem. It’s a symptom of a missing one step further upstream, at the exact moment an idea shows up.
I get an idea in the shower, or reading someone else’s post, or debugging something that turns out to be interesting for the some reason. I write it down in Keep or the notebook, and I feel like I did something productive.
I didn’t.
I moved the idea from my head to a slightly more durable piece of paper, and that’s all it did. Nothing in that step asks whether I’ll ever act on it, or when, or what “acting on it” would even look like.
There’s a name for the step I’m skipping, too. Getting Things Done splits capture and clarify into two separate stages on purpose: write everything down first with zero evaluation, then come back and turn each vague item into one concrete next action, the way “Bank” becomes “call the bank about the loan.” My system has the first half and skips the second completely, every time.
Half-finished thoughts don’t just sit quietly where you put them, either.
Sophie Leroy has spent 17 years studying attention at the University of Washington. She calls this attention residue: part of your focus stays attached to an unfinished task even while you’re doing something else entirely, and it gets worse the more unresolved the task feels. A note in Keep with no next action attached is about as unresolved as a task can get.
It’s not costing me time to sit there. It’s costing me a sliver of attention, 36 times over, every single day, whether I’m looking at it or not.
None of that shows up as a number until you go looking for it. I hadn’t, until I sat down to write this.
What a WIP limit is supposed to fix
The standard fix for a pile like mine has a name: Personal Kanban, a method built by Jim Benson around two rules and nothing else. Visualize your work. Limit how much of it can be “in progress” at once.
Benson’s own advice is to start at three, and his reasoning isn’t about resilience: three stickies are easy to see, and large enough to head off the arguments a limit of one invites. Below that limit, a fourth idea simply isn’t allowed to become active work until something already in progress ships or gets cut. That’s the parking lot with an attendant, in theory: the lot fills up, and the next car waits for a space.
Visualizing helped a little on its own: seeing all 36 in one place, instead of scattered across two apps and a notebook, is what made the number impossible to ignore in the first place. But a mirror isn’t a mechanism, and a mirror is all visualizing alone gives you.
Here’s where my version broke. I did draw the board, mentally at least (three columns, a limit of three in Doing), and I ignored it within about a week, because nothing enforced it.
A sign that says “WIP LIMIT = 3” with nobody checking is just a sign.
Cars don’t leave a lot because a sign asks nicely; they leave because someone eventually tows the ones that overstayed. My drafts folder had no tow truck, so 36 cars parked there and stayed.
That’s the piece most Personal Kanban explainers skip. The visualization is the easy 20%. Actually enforcing the limit, the part that requires you to give something up before you can start something new, is the other 80%. What it needs is a mechanism, not a whiteboard.
Making the limit cost something
The mechanism I landed on borrows from a tool I already use forty times a day: git. Before I’m allowed to open a fourth draft, I have to remove one of the three already in Doing, and removing one means one of two things. Either it ships (finished, moved to Done, same as any normal task), or I kill it, and killing it means writing an obituary.
Killing a draft looks like this:
git mv drafts/ts7-post.md archive/ts7-post.md
git commit -m "RIP: Microsoft shipped the real writeup before I finished mine"One line moves the file out of the way. The other line is the part that actually costs something.
That’s the whole mechanism, laid out as a loop:
flowchart TD
A["Doing column is full<br/>3 drafts at the limit"] --> B["New idea shows up<br/>no open slot"]
B --> C["Pick one to remove<br/>to make room"]
C --> D["Finish it<br/>ships normally to Done"]
C --> E["Kill it<br/>git mv to archive/<br/>commit says why"]
D --> F["Slot opens<br/>new idea can start"]
E --> FThe obituary is the part doing the actual work, and there’s a real reason a public commit message succeeds where a private whiteboard sign failed.
Kahneman and Tversky laid the groundwork for this back in 1979, in the paper that eventually won Kahneman a Nobel Prize: “losses loom larger than gains.” Their actual finding was that most people turn down a fair coin flip for equal stakes, even though it’s break-even on average, because losing feels worse than winning the same amount feels good. Put in smaller numbers than they used, and this part’s my example, not theirs: offered $20 on heads or -$20 on tails, most people say no, and the value function they measured is consistently steeper on the losing side than on the winning one.
Deleting a draft silently is a loss you can pretend isn’t one, since nothing marks the moment it happened. Writing git commit -m "RIP: ..." turns the same event into a loss you have to name, out loud, in a log you’ll see again. That small, deliberate discomfort is the tow truck.
It’s what makes the three-item limit something I actually respect instead of something I quietly work around.
What’s actually on the board right now
Three things, and I mean that literally: this post, a TypeScript piece I still believe in, and a build-tooling draft I give even odds of surviving the week. Two others got the git mv treatment while I was writing this, with an honest one-line reason attached each, more than they ever got sitting quietly in the folder for six weeks.
What makes the trick work is that quitting something finally costs me something I can see.
Cheers!
References
- How To: Setting Your Personal WIP Limit. Jim Benson, Personal Kanban. Why the limit starts at three, and what it isn’t meant to do.
- The Ultimate Guide to Personal Productivity Methods. Tricina Elliker, Todoist, 2015. The Getting Things Done capture/clarify split.
- Attention Residue. Sophie Leroy, University of Washington Bothell School of Business. Why an unfinished task keeps costing focus after you’ve moved on.
- Prospect Theory: An Analysis of Decision under Risk. Daniel Kahneman and Amos Tversky, Econometrica 47, no. 2 (1979): 263–292. “Losses loom larger than gains.”
Follow-up topics
- Day theming: splitting coding hours from writing hours instead of limiting WIP within each
- An energy audit applied to side projects instead of an executive’s calendar
- What Don’t Break the Chain gets right that a WIP limit doesn’t, and vice versa
- GTD versus lighter systems for a programmer who also blogs
- Six months of
git log archive/: what actually kills a draft, by category