Like others here, if I lose steam on one, I switch to another. The novelty effect is real. To support switching though I have to use a notebook. As I get to the point where a project is feeling more drag than energizing, I write down everything about it that I have in my head at that point into my notebook. Then I find another project I had left in that state, read the page(s) on it, and spin it up.
Still, my biggest problem isn't losing steam its simply too many choices. I need to get better at deciding I'm not going to do a project and putting it down for good.
Anything larger than a small project will need to be put aside for a while from time to time (for whatever reason), and I've found that making it easy to pick it up again is one of the most important things you can do.
My strategy for this (admittedly most suitable for software projects):
1) Write down your large, fantastic vision for the finished, complete project.
2) Write down the smallest possible feature that would bring you some utility. MVP, if you like.
3) Take this requirements and write an automated test at the highest level of abstraction possible. It should almost read like the MVP requirement you just formulated. That doesn't have to mean BDD, just something you can read easily.
4) Implement until the test passes.
5) Go to 2.
What I've found over the years is:
- Quickly reaching milestones of utility are key for keeping motivation while working. This is obvious, of course.
- The written down vision brings the motivation and big picture plan back when picking things up: Get your blood pumping again!
- The automated tests help keep implementation going when your drive falters. What should I do know? You should just make the test pass. Nothing harder than that. No need to think super hard. Just try to make it pass.
- The automated tests help you get hacking again without the immediate fear of breaking things: Get the ball rolling again, quickly and easily!
- The automated tests also serve as your requirement specification so far: You can easily see what already works.
Side projects are so important, and one should make it as easy as possible to sustain and restart them! Good luck!
I'm a bit confused by this approach. Is it related to some established design approach or principles?
What is MVP or BDD? Could you provide an example of your process?
Would it be similar to this example?
1. I want to put out a rpg for iOS.
2. Implement a pokemon style battle system -> when health < 0, NPC dies.
3. Not sure where automation fits in?
4. Code it and test until it works.
5. Move on to adding experience when killing an enemy, etc.
MVP occurs a lot on Hacker News, in that context meaning Minimum Viable Product, or the least amount of work you must do to make it useful for users/customers.
BDD in the software context means Behaviour-Driven Design and is an opinionated way of writing tests.
With regards to step 3 in your example: Sometimes it can be challenging to design automated tests for certain functionality.
For a game, it could be scripting "fake" user input that is supposed to have a certain end result, and then verify that that end result actually occurred. E.g., the player makes a few good moves, then a few bad moves that should cause health to drop below 0, then check that the player actually died.
Automated tests are a life saver, and often it pays off in the end to learn how to write them for almost any functional requirement.
Still, my biggest problem isn't losing steam its simply too many choices. I need to get better at deciding I'm not going to do a project and putting it down for good.