[cersa8]

For me it works best to start a project in such a way that it is easy to get back to. Fully expecting and embracing getting bored and leaving it gathering dust for a while.

For this to work I have docs folder with a todo.txt, architecture.txt, questions.txt and features.txt. I push it early to a private gitlab repo and use a language like TypeScript that makes it easy to come back to and make changes without fear of braking things. It won't be the first time that I get excited (again) by something and can continue on an existing project.

[dbrueck]

Yes! I keep a per-project journal file in each project's repo and it's so helpful when you end up having to take an unexpected break to bringing yourself back up to speed on why you made certain decisions or what the overall status was.

Something that also really helps is anytime I'm wrapping up a session on a project, the last thing I do before committing changes to git is to make a list of the next half dozen baby steps to complete. Without this, sometimes I'll come back to a project but only have limited time and I waste it trying to remember where I was, so a little hint from the past saying "jump in right here next time" is very handy.

[jonwinstanley]

+1 for a docs folder. It seems so ridiculous but I've come back to projects and can't remember where it's hosted, or how I deployed etc.

Great to have a few txt files that tell you how it all works, how you setup your server etc as it's surprising how much of your process can change over a few months/years.