_Photo by [Simon Migaj](https://unsplash.com/@simonmigaj) on [Unsplash](https://unsplash.com/)_
We've probably all been there, that boost of en...
For further actions, you may consider blocking this person and/or reporting abuse
After having had that problem for years, I started... writing stuff down :D
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 🙂
That's similar to what I do. I have a workspace in Notion.so (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.
Hey, thanks for mentioning Notion.so! Going to have to check it out. I wonder how i've never heard of it.
Yeah, great tool you note over there notion.so is impressive for this kind of tasks.😉
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!
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.
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:
feature/bugfix/hotfixan then the folder following by the current changefeature/cartModule/cartListDo 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
reviewthe entire mergeI 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!
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.
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.
Absolutely
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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... 🗓
Documentation and tests (I'd wish 😅)
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.
GitHub issues for sure - and ideally having some sort of external driver / goal. But to be honest I am definitely one for ‘oo I wonder if I could rewrite it in <insert framework of the month>’ 😂