Idea Overflow: The Struggle to Finish What We Start

I really like writing, sometimes I like writing a little too much, so much so that I end up having 5 half written but unfinished blog posts sitting idly in my Notion waiting for the day that I pick up my metaphorical digital pen and finish them. I feel like I have so much to say sometimes that I need to tell you about, or maybe helplessly rant about ;). This isn’t just limited to writing, not even a little, I, and likely you, have a dozen projects that “aren’t abandoned, and just waiting to be worked on again” even though 90% of the time we are just telling ourselves that to make ourselves feel better about moving on the the next thing, and sometimes we just need to push ourselves to press publish and be done with something, even though we might not like it, we can’t learn anything if we try to polish every minute detail.

We can never be perfect, as much as you may want to be, we’re imperfect, and nothing we can do will ever be perfect, and I know it’s hard to accept that when we sometimes push ourselves a little hard to be perfect, if we just tweak that color a little more, if we just made that sidebar a little smaller, maybe — just maybe, everything will click into place, but eventually we have to decide that what we have is good enough, and we can press publish, and iterate on the imperfect and maybe become even just that little bit closer to perfect.

Often, The first idea that comes to me is the first project that I get done, but eventually I get side tracked, or I set unrealistic expectations, and I don’t really finish a project, I get bored, play satisfactory for 120 hours, and start something else, leaving that project as a husk of what I originally wanted for it, it starts to rot in the dusty corner of my GitHub profile and I forget about it. My projects folder on my ssd is even worse, filled with half finished projects that I never deemed fit to see the light of the open internet, as they bit rot into nothingness, only to be remembered when I’m working on another project and I need that one component that this project has, reducing my previous work to a scrap heap to be picked through and repurposed.

More recently, however, I’ve tried to do a little better than this, doing smaller projects that solve an issue, or are really just for fun, to play with something new, or to learn something. To keep projects under control and avoid idea overflow, I've found a few strategies that work well:

• Have a clear end goal in mind before starting
• Carefully manage the project scope to prevent it from expanding uncontrollably
• Set realistic deadlines or completion dates to maintain momentum
• Utilize project management tools to stay organized and on track

While all of these can be good if you really want to hold yourself accountable, this isnt super accessible to everyone, and I think all you have to do is have an end goal in mind and keep the project’s scope under control. Don’t be afraid to take breaks, and have fun, after all, isn’t that why most of us do any of this.

If you’re like me, you probably have a folder called “Code” or something that just has a mess of disorganized projects, likely with a different folder name than the project name, and half of them are either a shell of a project, or something you started but never finished and doesn’t even compile. Let me tell you, Git is your friend, whether you self host a Gitea (like me), or Gogs, or if you don’t self host anything at all, always create a git repo. When you delete or archive the git repo, delete the folder too. If you don’t want your code visible to everyone, don’t be afraid to use private repos, GitHub has unlimited private repos, and self hosted services don’t even open to the internet at all.

A big thing that I would suggest doing as well is documenting your projects, I know we all hate it, when and what to document something can be scary, but trust me, later down the line, when you look at some code you’ve written and see “We do this for xyz reason” you’ll go “oh, that’s smart” or, hopefully you’ll go “that’s dumb, instead, you can do it this way”. Taking internal repo documentation can be super helpful in the future too, I like using Obsidian.md but you can use anything really, just put anything you think might be useful and give a refresher a few months later if you come back.

Create a collection of components that you built, but keep coming back to, and if you modify the component and make it better, update it in the git repo so that you’re never asking yourself “hmm, I remember I built the nav in project 1, but I updated it later, what project did I even use it in? Where did I modify it? How many different variations of it do I have?” Instead, you can take a look at that component repo and get the newest version, or, you can look back at the history and take the old version, you can keep your old components in a legacy branch, etc. Git is so powerful, even for something as simple as a small collection of components, it will be unbelievably helpful.

If you, like me, have Idea Overflow problems, when you get an idea, write it down somewhere, anywhere you’ll be able to find it later is good, and go back to what you were doing. Don’t drop everything and start working on the next project, because then you’ll end up with the skeletons in the corner of your git account that you avoid talking about that I discussed earlier. Once you get done with a project, take a break, or if you want something else to do, take a look at your project ideas paper and pick one.

I know it’s exciting to change pace, but if you never complete a project, all you’ll be doing is chasing new project after new project rather than grand takeaways from seeing a project to its end.