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:
So,
Top comments (24)
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.