DEV Community

Cover image for How do you get back into a side project after months?
Christian Vasquez
Christian Vasquez

Posted on • Updated on

How do you get back into a side project after months?

_Photo by [Simon Migaj]( on [Unsplash](

We've probably all been there, that boost of energy late at night that doesn't let us go to sleep while our mind is bombarded with cool ideas about a new project or tool we want to use.

Your turn on your computer, break your sleep habits for a few days and then never look back at it after months because being an adult is hard.

But then... one day, you come across that side/pet project again in your GitHub Graveyard and the spark starts to come back at you again.

You git clone the hell of out it and when you finally open it you are just like:

Dog astronaut lost in space


What helps you to get back on track?

Top comments (24)

andywer profile image
Andy Wermke

After having had that problem for years, I started... writing stuff down :D

  • I create issues in GitHub, not only for what doesn't work yet, but also for features I want to add in the future
  • I create pull requests when introducing code changes, even if there is no one to review them
  • Oftentimes before I start working on it, I collect my thoughts on what I want to achieve and what pain I have that I want to solve

Not too detailed, a few bullet points per idea usually do the trick.

Doesn't take much time, but when I come back after pausing for months, I can just read up on my initial motivation and plans, as well as getting an overview of what I was doing before I left.

Plus: Not having to worry about forgetting good lines of thought is a very comforting feeling πŸ™‚

marissab profile image
Marissa B

That's similar to what I do. I have a workspace in (great tool for organizing btw) that has everything for a major project, from ideas to tasks and rudimentary user stories. If I leave a project and come back to it, ideally I can grab whatever task was next on the pile or review what I had planned next.

foresthoffman profile image
Forest Hoffman

Hey, thanks for mentioning! Going to have to check it out. I wonder how i've never heard of it.

areknawo profile image
Arek Nawo

Yeah, great tool you note over there is impressive for this kind of tasks.πŸ˜‰

chiangs profile image
Stephen Chiang

Hey notion looks awesome ...I use boostnote to keep track of everything, but it's not as full featured yet.

Might be interesting to try out!

tiguchi profile image
Thomas Werner

Same here. I write tickets and high level overview documentation as if I would on-board a ton of other developers in the future. In the end that stuff is super helpful getting back on track months later. So practically I'm doing myself a favor, not other people. It's also important to write as if you were explaining to someone who doesn't share the same knowledge at the time you're writing it. Makes it much easier to jump right back when memory faded quite a bit.
Also prioritizing tickets at a time where knowledge about the project is fresh, helps getting back on track quicker.

mfcarneiro profile image
Matheus Felipe

A little addendum:

I do the same! Issues and pull requests on Github is a very handy tool to improve productivity and stay aware of the project, even not working in a time on that repo.

I'm trying something in a few weeks that works a ton for me, I usually do like this:

  • Create a branch signing with is a feature/bugfix/hotfix an then the folder following by the current change


  • Do what is necessary on project, and go for a commit. Here is a awesome stage that I recommend the most

  • All set up, then I merge to master, always set this branch up to date

  • I find super useful in this merge process: code review! in each final merge, I review what is done and anything that comes in my mind, I comment on the lines or review the entire merge

I think that is a good way and you have all the information within the repo, not having writhing elsewhere that you can easily forget

Any ideas to improve is very welcome!

ben profile image
Ben Halpern

I think: Not being afraid to rewrite big chunks. There's a temptation to build on old work, but unless it was really well done last time, you may need to toss some of it aside and start over.

In terms of preemptively making this easier, being sensible with dependencies is a big one. Simpler, dependencies that don't complicate build means less burden to pick something back up IMO. Things that require complicated build steps are hard to pick back up after time away in my experience.

abraham profile image
Abraham Williams

It's also important to keep in mind that you don't have to write good code and you don't have to rewrite bad good. A poorly written thing that does what it's supposed to is better than the most amazing code that doesn't do anything.

ben profile image
Ben Halpern


bgadrian profile image
Adrian B.G.

The amount of "need + desire" must be greater than the technical debt.

Is hard, fortunate my last projects were made public so I forced myself to keep a minimal amount of docs, tests, scripts and clean code.

niorad profile image
Antonio Radovcic

It's like picking up a game after a longer break: you forgot the controls, so you re-do the tutorial.

Wouldn't that be an idea? Always keep the readme updated with the latest todos and build-instructions?

I don't like the "start super clean" and "write tests" mentality for smaller personal stuff. Why spend so much time on that before I even know the thing is going somewhere? Once I'm at the point that I'm sure I want to make a product/open-source-project/etc. out of it, cleaning up and refactoring will be the smallest issue.

cjbrooks12 profile image
Casey Brooks

Depending on how large/complex the project is, I will sometimes start with a completely new project with better architecture, and then pull code as-needed from the older codebase, refactoring it along the way. It helps me to re-orient myself in understanding the intent behind the project while not getting bogged down in the messy details, and makes it easier to update the code without breaking everything.

frederikheld profile image
Frederik Held

Actually that's the reason why I do a lot of documentation. Otherwise I just wouldn't remember why I did it this way. And often not even why I started it in the first place :-P

Whenever I start a new project, I ask myself: which questions will my future self ask? Then I write the code so that he will understand and a good documentation, that explains the concepts and design decisions. And of course, how to get started.

jackharner profile image
Jack Harner πŸš€

For me, more or less, it's just kinda poke around the project. I'll be looking for things to fix/improve, find something, fix/improve it, and repeat. Eventually that just snowballs into reworking larger and larger chunks or adding stuff that I've used in a new project since I started the old one.

More or less just get the ball rolling again.

oksoimdave profile image
dave medlock πŸ§”πŸ»

I keep copious and detailed notes in Evernote for all my projects. I break things down step by step and my notes are often a sort of stream-of-consciousness where I record what went wrong, what worked, what didn't work (and most importantly why). I keep my "to do" items in there as well so that I have the whole context of what was happening, where I was, and since I never know when I'm going to have to disconnect from a side project for a week or a month, it's really important that I leave a "what's next?" Note for myself so that I can jump back in fairly quickly.

jaredgeddy profile image

I use scrum for everything I work on. Including personal projects. The main reason being for those times. I know I'll lose interest, life will get in the way, and eventually that spark of energy will come back as you mentioned.

However, when it does it's hard to know where to start... unless you had a project to go back to and see where you were in the project. At the very least I've found it helps remind me what features I did complete and which I didn't.

Also I'd recommend spending the first day or so poking around your code, reading your comments, even refactoring some of it. The reason you feel lost is both not knowing where to start and it feeling like someone else's code in some weird way. You just have to make it your own again.

beesnotincluded profile image

I think the best hope is to code to an even higher standard than you would in your day job. That way you have the best chance to get back into it later on and you have the enjoyment on working on something that isn't hastily cobbled together. You also get the reassurance that even if you don't pick it up again, you've honed your skills in the process.

emgodev profile image

Something that helps is, depending on the project, using what I've learned to rebuild it and make it more relevant or up to date. I've been taking some old smaller snippets I started on Codepen to practice modern frameworks like React or Vue. I had an old project I was working on in LAMP and converted it to MERN. I feel doing this makes it all very exciting and I can still re-use the design I've already built and rebuild the structure.

A lot of people are saying documentation. Lately I have been not documenting my code. In particular I have been trying this with my library, I have a docs/ folder dedicated to function specific pages showing example code and a link to a Jasmine unit test for that function. If I make changes I need to update the pages individually, but it feels less messy this way.

Also a lot of the need & desire others have commented, starting over, refactoring, one guy said taking what works and starting with a new architecture.

casperns profile image
Zelimir Stefanovic

Documentations with a loooot details.
Maybe, in that moment you think it's not necessary, but for a few months, every sentence, every word will be helpful.

c0il profile image
Vernet LoΓ―c

I am using an habit tracker: I must work on my side projects every day. (current streak 350) So the real question is "How to not quit the track?". . So you don't have to ask this question "How to get back on track?". πŸ™‚

But to answer your question, If I abandon my main side-project for six months, I have a big markdown readme file with all has to be done: todos, cleanup/refactoring, devops, design... πŸ—“

herrfugbaum profile image

Documentation and tests (I'd wish πŸ˜…)

gklijs profile image
Gerard Klijs

I try to have at least a minimal readme with how to run/test/deploy the stuff however relevant or non idiomatic worked great so for. Also try to write clean code even if it's for a pet project.