My Drafts Folder Is a Graveyard, and a WIP Limit Fixed It, So Far
· 5 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 formal next step after that. Nothing enforces the “idea” into “task.” It just sits there next to a dozen other notes until I think its worth doing or 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.
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 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.
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.
Experts say unfinished thoughts eat at your focus and hurt you. 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 multiplied by how many I have unresolved, every single day, whether I’m looking at it or not.
What a WIP limit is supposed to fix
The standard fix for my unresolved pile is a Personal Kanban, a method built by Jim Benson around two rules. Visualize your work. Limit how much of it can be “in progress” at once.
Benson’s advice is to start at three, and his reasoning isn’t about resilience: three stickies are easy to see, and large to avoid arguments. Below that limit, a fourth idea simply isn’t allowed 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: my first idea of moving all 36 in one place was good. Instead of scattered across two apps and a notebook. I can concentrate on acting on them.
Here’s where my system fell apart. I drew the board but I was not disciplined enough to enforce it. I look at a sticky and either work on it or put it back so I can get back to it later instead of decisively cutting it. That was the issue.
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 everyday: 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 flowchart:
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 RIP is the part doing the actual work, and there’s a reason a public commit message succeeds where a private whiteboard sign failed.
Kahneman and Tversky laid the groundwork for this back in 1979, in a 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. If offered $20 on heads or -$20 on tails, most people say no. This is called Loss Aversion.
Deleting a draft silently is a loss you are OK with it most of the time, 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 can see anytime. That small, deliberate discomfort is the tow truck that pulls the car who overstayed its welcome.
This step is what makes the three-item limit something I actually respect instead of something I quietly work around.
I recommend wrapping the commands in a bash script or git alias. Easier you make the action the more you will use the step.
Here’s a git alias definition:
git config --global alias.abandon '!f() { local msg="${2:-abandoned $1}"; git mv "drafts/$1" "archive/$1" && git commit -m "RIP: $msg"; }; f "$@"'Usage:
git abandon some-draft.md "draft angle is thin"Caveat: Although I have tested this git alias extensively. Make sure to test it on a non-critical code you currently have first. It works on bash on a Mac, Linux might support it too. I would check in WSL2 in windows.
Don’t be tempted to extend the script to recursively run on all contents of a folder. The single draft triage makes it deliberate and makes the step hurt more. The “loss” we are looking for that makes system work.
What’s on the board right now
Three things: this post, a TypeScript piece I still believe in, and a build-tooling draft I give 50/50 surviving the week. One other got the git abandon treatment while I was writing this, with an honest one-line reason.
What makes the trick work is that quitting something finally costs me something I can see.
Cheers!