On Finishing Things

I have a folder called projects with 47 items in it.

Maybe 8 of them are finished. The rest are in various states of abandonment — some died after a weekend, some after months, one after almost a year. A few I still think about. Most I’ve forgotten why I started.

For a long time this bothered me. I told myself I had a finishing problem. That I was good at starting and bad at completing. That I needed more discipline, more accountability, a better system.

I tried more discipline. I tried accountability partners. I tried systems.

The ratio stayed roughly the same.

What I think is actually happening

I’m a builder. Not in the LinkedIn sense — in the sense that the part of a project I find most engaging is the part where you’re figuring out how something works, making early architectural decisions, seeing a rough shape emerge from nothing.

The later stages are different. The polish, the edge cases, the documentation, the maintenance. These are real work, often important work. They’re just not the part I’m drawn to.

This is, I think, a feature of how I’m wired more than a character flaw. And I’ve started to make peace with it.

The case for unfinished things

Not every project needs to be finished. Some projects teach you what you needed to learn and then you move on. Some are experiments that answered the question. Some are just fun to spend a weekend on.

The cultural pressure to ship is real — especially in tech, where “done is better than perfect” is repeated until it becomes a reflex. But done-ness isn’t the only measure of value. A half-built thing that taught you something is worth more than a shipped thing that taught you nothing.

I’m not arguing for never finishing things. I’m arguing against reflexive guilt when you don’t.

The things worth finishing

That said, some things genuinely need to be completed to be useful. A blog post that’s 90% done is effectively zero done — no one reads it. A side project that almost works serves no one. A promise you almost kept is still a broken promise.

The skill, I think, is knowing which category you’re in. Figuring out, early, whether a thing is a learning exercise or a commitment. Treating those differently.

For the learning exercises: give yourself permission to stop when you’ve learned what you came for. The unfinished state isn’t failure — it’s conclusion.

For the commitments: you have to find the part of the later stages that connects to why you started. For me with writing, it’s the editing pass — seeing something messy become clean. For code, it’s the moment the tests go green. Find the anchor.

On this blog

This post is me trying to finish something. To take a thought I’ve been circling for months and actually write it down, all the way, including the ending.

I don’t know if I have a clean conclusion here. I think the honest answer is: I’m still figuring this out. The 47 projects are still there. I’m trying to be more intentional about which ones I commit to and which ones I’m allowed to let be what they are — useful experiments, not unfinished failures.

That’s progress. I’ll take it.