Your Drafts Are Not Source Code

The folder was called drafts/. It sat right next to the application code, the database migrations, the build scripts. I opened it last week and found article drafts from the past two months, three old research outputs from agent jobs, two markdown files describing skills I'd long since deleted, and a .DS_Store for good measure.

It had become a junk drawer wearing the label "drafts."

The technical fix is dull. Runtime data is not source code. Clone the repo on a fresh machine and you shouldn't get a copy of my personal half-finished article about creative tax. Conversely, my half-finished article shouldn't disappear if I rename the repo. The two things have different lifecycles. They want different storage. So drafts move to their own home outside the codebase, the codebase stops carrying them, and everyone is happier.

That part takes an afternoon.

The interesting part is what happens before the afternoon. The folder didn't start as a junk drawer. It started as a perfectly reasonable place to put one or two drafts while I figured out where they should actually live. Then I figured out where they should live, but the folder was already there, so I kept dropping things in. Then research notes wandered in because they were also markdown. Then skill specs because they were also "stuff related to the project." Then job outputs because nobody ever told them not to.

By the time I looked at it again, the label on the folder was lying to me. It said "drafts" and it meant "things I have not yet committed to a real home."

This is the same thing that happens to every writer's filesystem.

You start with a folder called Articles. It's clean. Then you drop in a research file because the article needs it. Then a reference piece because you might quote it later. Then a half-started piece you abandoned, with an opening that might still be useful. Then a paragraph you cut from another article but want to save just in case.

Six months later the folder has eighty things in it and you can't tell what's actually publishable from what was just on the way to being publishable.

The trouble isn't the contents. The trouble is that the folder name has stopped doing any work. It's no longer a category. It's a collection.

A real category narrows what belongs inside. You can look at any one item and decide cleanly whether it belongs there or somewhere else. A collection is the opposite. The boundary is fuzzy, the contents drift, and you start to feel a vague pressure every time you open it, because nothing inside is quite where it should be.

This matters because the categories you use shape how you can think about the work.

If everything in your writing folder lives at the same level of finish, you can't tell what to push on next. If your codebase carries your drafts, the codebase looks bigger and messier than it actually is. If "research" mixes with "outline" mixes with "finished," you've lost the ability to see your work in stages. The categories are doing the seeing for you. When they decay, your seeing decays.

The fix isn't more folders. It's better-shaped ones.

Pick categories that describe a stage of work or a kind of object, not a topic. "Drafts in progress" beats "drafts." "Published, ordered by date" beats a folder that contains both. Research notes get their own home. Reference material gets a different home. The shape of your tools should match the shape of your work, and the shape of your work has stages.

When you make this honest, two things happen. You see the actual size of each pile. And you start to feel friction when you try to put something in the wrong place, which is exactly the friction you want.

The codebase has a clean drafts directory now, and the drafts directory has a clean home, and the home is somewhere both my Studio and my Mini can reach but my git history cannot. It is not a glamorous improvement. Nothing about the published articles is different. But the folder is no longer lying to me, and a folder that tells the truth is worth more than it sounds.

Whenever you find a folder that has stopped being descriptive, the folder is the message. Look at what crept in. That's the category you were missing. Make a home for it. The original folder becomes itself again, and the work it's holding becomes legible.

When in doubt, ask the label what it means. If it can't answer cleanly, the label has work to do.