
Ask HN: How do you quickly get back into a side project after several days? - webmasterraj
I don&#x27;t get a chance to work on my side project every day. So I&#x27;ve noticed an annoying &#x27;reload&#x27; time when I come back to it after a few days, that it takes to figure out where I was and how to get started again. To help, I&#x27;ve found myself keeping a simple log in a text file with notes to myself. It&#x27;s not great, and I&#x27;m sure there&#x27;s a better way. (By log I mean something different than commit messages. It&#x27;s more like a personal journal, with notes on what I did, where I left off and what I have to do next.)<p>Does you do something to optimize how quickly you get back into a project that you only get to work on occasionally? E.g. I have a friend who chats with Slackbot in a private room, though I&#x27;m not sure it&#x27;s much better than a text file.
======
DodgyEggplant
(1) Stop working in the middle of something, so when you get back you don't
have to guess what next. It's an old hack (2) Keep a "what's next" list of 3-5
items, in addition to the project plan/to-do list (3) Do try to work, or just
open it, every day. Even 15 minutes a day. It's not only the time you work on
it, but also you keep thinking and solving and innovating during the day

~~~
webmasterraj
I like hack (1) a lot. But at least for me, it's hard to stop my brain when
it's in the middle of something, I have this rush to get it done, which is why
I like working on my own stuff of the side.

But maybe stopping at a reasonable midpoint without, like a subfunction, is a
good idea. What kind of midpoints do you use?

~~~
DodgyEggplant
Nothing special, really. On a virtual machine you can even leave everything
open as is, so it's ready to continue. If I'm near a commit, I will not commit
until next time. Then I start with the commit review, and commit.

------
greenyoda
I'm not currently working on any personal projects, but at my job I'm
constantly juggling several projects whose priorities keep changing. And for
many years I've been doing exactly what you do - keeping logs in text files.
Long-running projects get their own text files while smaller projects get
recorded in a "daily log". I like text files because they're easy to grep for
keywords, and because a simple text editor is free of distractions.

I find that this is even useful in the short term: if I'm working on some code
and need to go to a meeting, it's easier to get back into the code later if I
have a record of the last thing I did before I was interrupted.

------
otoolep
Definitely a real issue, I hit it myself.

Assuming you commit when you stop, why not make the commit message detailed
enough to summarize a) where you are, b) what problems you are currently
experiencing, and c) where you think you need to go next. Explicitly think
what your future self needs.

I certainly value of design notes (even for small projects), but committing
regularly and often to a git repo for the project (it doesn't have to be
complex, a simple local repo will do) seems like the ideal amount of tracking.
It generally works for me.

------
krapp
I can leave side projects alone for weeks or months at a time, so I've gotten
into a habit of having a tab in my text editor (Sublime Text) with nothing but
notes to myself for that project.

