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.
You might like Notion, Obsidian or similar note taking apps - using it as basically a stream-of-consciousness tool, recording what you've tested, those notes you mentioned, but also being able to embed code, screenshots, etc. _all in-line_ really helps with the context reacquisition. Just lookup the shortcut to insert the current datetime (Evernote was "ctrl+;", Notion I think the best is probably "@now") and you've got good timestamps as well.
I'm not super familiar with Obsidian, but from your general description I think it might work best - I _think_ you can just have your (markdown?) Obsidian file in the project folder like you mentioned.
I'm aware of various information management tools, but exploring these tools, getting familiar with specific syntax or intricacies of usage needs a higher activation energy than simply running $EDITOR and typing away.
I'm usually working on hardware that's at least a couple of years old, and the experience with modern day desktop applications (websites in an Electron-wrapper, if you will) is that they're terribly slow on relatively okay, albeit older, hardware. Not to mention (but I haven't checked!) that you'll need the application to search through your content, perhaps due to the use of some database, instead of grep(1)ing for keywords inside text files. I'm not opposed to optimized, application-specific search, but, for personal usage, if I need the application to search through content, this makes data portability much more difficult.
I will say (because you specifically pointed out you haven't checked - I do enjoy clear and honest communication online) that Obsidian at least deals with straight Markdown files, so while (per my current understanding) the program itself isn't OSS, the datafiles are all easily importable into other systems, and the files themselves are grep-able and mostly human readable (all text is there, but extra features and layout will not show up as nicely as in a Markdown-specific renderer) in any text editor.
In addition, I've started writing failing (or empty, in the framework I'm using empty fails) tests as a todo for the next time I pick it up, so by generally keeping the tests passing I know what I was intending my next step to be when I last worked on it a week ago.
I feel there's a good universal principle underneath the advice to write tests and have good test coverage, but there are lots of situations where tests are not an option.
I'm working on a shader for a video game, any advice on how I can write some tests for it?
I'm less familiar with video games but I'm sure there's tests you could make with shaders. You could test that the shader compiles properly, you could render it to an image and compare the result, give it different parameters and see how it behaves...
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.
You might want to look at Coping Strategies for the Serial Project Hoarder [0]. It's a blog post by Simon Willison who maintains a lot of projects. Even if you have only one, I think his strategies apply well to making progress regardless of whether you can work on your project everyday, or only once every couple of weekends.
The best tool for that is discipline. Very difficult to learn tho. But seriously, many tools do the work (lets say, obsidian) if you do the most important thing that is to be consistent
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.
I think it gets even more complicated than that, as if you’re not careful, you might end working on something you made only for yourself, but evaluating its success by public metrics. This can then lead to canceling the project altogether because its public reception was not as good as you’d hoped - even when you only made it for yourself in the first place.
Yeah, if your blog or what have you has an actual following. You can always write to yourself or record to yourself and just treat it like a journaling activity.
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.
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.