Ask HN: How do you quickly get back into a side project after several days? | Hacker News Reader

Ask HN: How do you quickly get back into a side project after several days?

7 pointswebmasterraj6 comments

I don't get a chance to work on my side project every day. So I've noticed an annoying 'reload' 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've found myself keeping a simple log in a text file with notes to myself. It's not great, and I'm sure there's a better way. (By log I mean something different than commit messages. It's more like a personal journal, with notes on what I did, where I left off and what I have to do next.)

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'm not sure it's much better than a text file.

View on HN

(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

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?

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.

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.

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.

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.

Reply on news.ycombinator.com