On Finishing What You Start (Coming From Someone Who Has 80 Unfinished Repos)

I am going to write about finishing what you start, and I want you to know up front that I have more than 80 repositories, and most of them are unfinished. So this is not a lecture from someone who has it figured out. This is a confession and an investigation, from someone standing in the middle of his own graveyard of side projects, trying to understand why some lived and most died.

The graveyard

Every developer has one. The project that was going to be the thing. The idea you were sure about at 2am, that you started with real energy, and that now sits frozen at 60 percent, last commit months ago, README half-written. My GitHub is full of these. Skeletons of enthusiasm. Each one a moment where I cared enough to start and not enough to finish.

Starting is cheap. Anyone can start. The graveyard is full of starts. Finishing is the rare thing, and it is rare for reasons that have almost nothing to do with the code.

Why they die

I have thought about this a lot, and the projects do not die for the reasons I tell myself. It is rarely that the idea was bad or the problem was too hard. They die for quieter reasons:

• The interesting part got solved. Once I understood the hard bit, the remaining 70 percent was just labor, and labor is not why I started.
• A newer, shinier idea showed up and stole the energy I was supposed to spend finishing this one.
• The project was never a commitment. It was a curiosity, and curiosity has no obligation to finish.
• Finishing means exposing it to judgment, and an unfinished project can never be judged a failure. The graveyard is also a hiding place.

That last one is the uncomfortable one. Some projects stay unfinished because finishing them means finding out whether they were any good. As long as it is half-done, the dream is safe.

The three that made it

But some did make it to production, to real users, to actually mattering. And when I look at what was different about those three, it was not that they were better ideas. The difference was structural:

They had an external commitment. A client, a deadline, a person who was waiting and would notice if I disappeared. The accountability lived outside my own fragile motivation. My own enthusiasm is a terrible engine, it runs hot and dies fast. An obligation to another human runs steady.

They had a real, narrow definition of done. Not "the best version imaginable," which is never finished, but "this specific thing works for this specific person." A finish line I could actually cross, instead of a horizon that moves every time I get close.

What finishing actually means

Here is what I have come to believe. Finishing is not about the final commit. It is about crossing from "this is for me to play with" to "this is for someone to rely on." That crossing changes everything. The standards go up. The boring 70 percent becomes non-negotiable. The thing has to actually work, not just demonstrate the clever idea.

A hobby project and a commitment are different species, and I had been confusing them for years. The hobby project is allowed to die. That is fine, that is healthy, that is how you learn cheaply. The problem is only when you wanted a commitment and built a hobby, when you needed the thing to ship and never gave it the structure that makes shipping happen.

What I am doing about it

I have stopped feeling guilty about the graveyard. Those 80 repos are not 80 failures. Most were never meant to be finished. They were curiosity made visible, and they taught me things I use every day. But for the projects I actually want to ship, I have learned to give them what the surviving three had: an external commitment, a person waiting, and a narrow definition of done I can actually reach. Motivation does not finish projects. Structure does. I learned that from a graveyard, which is, I suppose, a finished thing in its own way.