Making progress on side projects with content-driven development

Another post (https://news.ycombinator.com/item?id=41148517) suggested "outline speedrunning" or "recursively outline". The gist: write outlines and recursively write outlines for those outlines until the items are small. I think that method complements the authors post.

One thing I'm doing since a few months is creating a fresh directory for every side project I start. Even if it's just "I wonder if I can (easily) extract all course information from this really slow school website that only offers a search bar" (it appeared to be easy). For a bit of structure, each directory starts with YYYYMM and a dash, and a few keywords that remind me what next side project I just started.

Inside the directory, there should be at least one text file containing steps I took, ideas I had, or URLs I visited, to provide my future self a nice amount of context whenever I'm revisiting that side project. For the course information side project, simply documenting the steps I took in the browser while visiting the school's website and just pasting the 'Copy as cURL' command for a certain request inside that file is sufficient! (I'm aware there's a lot of knowledge hidden in that previous sentence; it's more an example of writing down what steps you took while tackling the problem)

The directory listing, over time, should also give a nice insight of all the things I've discovered, tried, or perhaps even finished.

My advice for side projects, ship something the same day. Avoid leaving it in a broken state everytime you work on it.

This both helps keep the feature creep and complexity down, and makes sure you always have a running demo to show or play with.

Side projects should be all fun, if they are not, its not a side project its a second job.

I have found that one of the more useful things for me in most projects is having a readme per folder that has some basic info about each file in the folder, then can add more information as needed. That way when I leave for a while I know what I was thinking in one sentence when I made a file, and additionally might be able to split it to a package if it appears to be forming into a useful stand alone chunk. For larger projects I do a markdown checklist and break up smaller as needed. One of gets overwhelming to see what is done or not, I pull out those not complete yet into another file and wrote a current task from it and why it what it helps get done after. Sometimes my notes asking the way may include consider writing on this, which I totally agree does give a different approach sometimes. Really had fun reading your thoughts.

I’m planning a side project starting in October 2024, and it’s a big one. I have ambitious goals for it. Are there any recommended tools to help open-source projects stay focused and avoid distractions, especially when the initial phase could take over six months? I’m familiar with GitHub’s tools but would like to know about other best practices in this situation. Especially on project planning and other stuff.

Isn't there a distortion in decision making in projects when you start sharing about progress and become dependent on opinion? Not all projects are created for the public.

One of the unexpected pitfalls I've found doing the content driven approach is that I can tend to focus on technically complex tasks I can write about instead of core feature work. In general, however, this approach has worked fantastically well for me.