> Maybe, just maybe, if I set things up right, this effort will be worth it.
Worth it how? For your own curiosity or in some meaningfully productive way for your future self?
> Maybe in the future I will want to know exactly what the thought process that made me choose one font over another was
Maybe, but if it's trivial it's trivial so you don't need to remember it. If it was something you spent a lot of time deciding you probably are going to remember it anyway - if it was important. This kind of historical decision documentation becomes more useful when you have teams and want to onboard new people (and even then it has a limit)
> Do you have any suggestions? How do you stop yourself from overthinking and over-engineering task/project management?
For single-person projects you can go very simple. Most people are worried they're going to forget important tasks, but important tasks have a way of coming up again and again. I think storing list of items in a simple todo app or on paper is about all you need - this list can be as long as you want, but the longer it is the more diminishing the returns. Choose some small set of priorities you will do today - maybe 4-6 items. Do those then move down the list. Feel free to re-prioritize frequently.
> How do you determine what is worth specifying/documenting/archiving, and what should be ephemeral and only exist for the sake of facilitating taking the next step?
Specs are most useful in making you write, and thus helping you think. If you can't write it down you probably don't understand it. Small tasks don't need a lot of writing because you understand what you need and why. Specs are worth writing for the big items if you need to force yourself to think deeply. They're not important for historical purposes - once the feature, project, whatever is done, the spec is no longer needed. And in fact it's not very useful to review again as it's always better to review the thing you actually built instead of the spec (which in most cases will differ). Documentation (how to use the thing) can be useful if you want your future self to remember or others to use it - so document APIs, Libraries, things like that. Don't spend time documenting self-explanatory functionality.
Worth it how? For your own curiosity or in some meaningfully productive way for your future self?
> Maybe in the future I will want to know exactly what the thought process that made me choose one font over another was
Maybe, but if it's trivial it's trivial so you don't need to remember it. If it was something you spent a lot of time deciding you probably are going to remember it anyway - if it was important. This kind of historical decision documentation becomes more useful when you have teams and want to onboard new people (and even then it has a limit)
> Do you have any suggestions? How do you stop yourself from overthinking and over-engineering task/project management?
For single-person projects you can go very simple. Most people are worried they're going to forget important tasks, but important tasks have a way of coming up again and again. I think storing list of items in a simple todo app or on paper is about all you need - this list can be as long as you want, but the longer it is the more diminishing the returns. Choose some small set of priorities you will do today - maybe 4-6 items. Do those then move down the list. Feel free to re-prioritize frequently.
> How do you determine what is worth specifying/documenting/archiving, and what should be ephemeral and only exist for the sake of facilitating taking the next step?
Specs are most useful in making you write, and thus helping you think. If you can't write it down you probably don't understand it. Small tasks don't need a lot of writing because you understand what you need and why. Specs are worth writing for the big items if you need to force yourself to think deeply. They're not important for historical purposes - once the feature, project, whatever is done, the spec is no longer needed. And in fact it's not very useful to review again as it's always better to review the thing you actually built instead of the spec (which in most cases will differ). Documentation (how to use the thing) can be useful if you want your future self to remember or others to use it - so document APIs, Libraries, things like that. Don't spend time documenting self-explanatory functionality.