Hacker News new | ask | show | jobs
by thr0waway1239 3557 days ago
I agree with the predominant two suggestions here: to use Trello, and to do a little more planning up front.

But it also looks like you are having some issues with getting back into the zone quickly, without too much overhead. A trick that writers use is to apparently write an incomplete line at the end of the draft. You can try something similar - depending on your project, this could be something as simple a quick note on something you can do in exactly 5 minutes the next time you set down with some detailed steps if possible (for additional context).

Its just a suggestion, which is unfortunately not backed by personal experience (I have faced other challenges with my side projects but not the one you mention).

1 comments

Trello and writing a line are great; I have one extra comment about the line.

Instead of just "not finishing" something, I will do a minor brain dump of what I'm trying to accomplish into a comment or a Trello item in the details field.

Usually when I'm stopping it's because there's a thing that isn't easy to finish, and I've done a lot of thinking about how to finish, but don't have the time to do it. So I write down all of my thoughts on the topic -- sometimes it can run to several paragraphs and sometimes a table or two.

But the next time I pick it back up, I can totally get back into the right mental space quickly. The best part? After a break, even if I have a plan outlined in the comment, I often can immediately see a better solution than the one I was working toward.

On a related point I've been keeping a journal with similar notes in it; I've found this to be extremely helpful for thinking through problems. You've heard of explaining your problem to a rubber duck? Having to not only put the problem into words, but writing those words down, is a great way to get the brain churning -- and a great way to leave a map for yourself later to get back into a project.

I can second this. It's like rubber duck debugging but "past you" is explaining it to "future you" who is in a different mindset.

Most of my biggest breakthroughs have happened because of something like this.

And if you aren't afraid to check these brain dumps into your source control in some kind of notes.md, it can also give you a bit more context on what problems you were facing at that time in the repo's life, and perhaps why you thought the solution at the time was a good one.