That used to be me when I was younger. Now with a few more years of experience under my belt, I get more of my personal programming ideas done than ever before.
The secret?
There is none. I'm just better at organizing myself for my goals. I used to go about cool programming ideas like this:
1. Have an initial idea and get really excited about it
2. Clearly see in my mind how I would implement it
3. Think "this can't take more than a week!"
4. Start coding frantically, making sure to have an elegant, modular, reusable code-base
5. On the way, come up with more and more super-cool features
6. Think about every little detail of every feature and make sure implement it "the way it should be done"
7. Give up after two weeks because the project has become overwhelming and despite a massive code-base is not anywhere near a first usable prototype
I think the problem starts at 3. (maybe at 2.) and then gets successively worse all the way down. These days, my workflow looks perhaps more like this:
1. Have an initial idea and get really excited about it
2a. Do a reality-check, find it's probably not worth bothering in the big picture and do something else instead
2b. OR: if I really think the project is small enough, go ahead and give it a go.
3. Think of what the really cool features of the idea are
4. Remove them all and thus come up with a stripped-down, barely even usuable version of the initial idea.
5. Implement it in the most minimal, hackish code base possible: hardcode everything, ints instead of enums, strings are your friend,...
6. Actually finish this bastardized version of the initial idea!
7. Only then decide if it's worth going on from there toward the initial bling-bling idea by means of refactoring and refining or adding more features
Usually, by the time I get to 7. I decide I don't need it - either the version is actually good enough already (meaning the initial grandiose vision was over the top) or it has become clear already that the excitement of point 1. was unwarranted and I probably should have gone for 2a. instead of 2b.
In rare cases, however, I do stay in step 7. and improve upon the initial prototype iteratively. This can even go on for an extended period of time. But even then I'm trying to make sure that I stay true to the same method which can probably be summarized with the following question you have to keep asking yourself:
How can I achieve my goal with the least amount of work?
For me, I've realized it's paramount that I get to a result quickly - that is more important than properties like "with the most beautiful architecture" or "with the best possible UX" etc. You might think that 2a would lead to less stuff done, but in the end I think it actually leads to more mini projects actually becoming a reality.
Might I suggest that whilst it's great to get to completion pretty quickly and have many completed mini-projects under one's belt, that there might be some value in younger programmers choosing the untenable-but-beautiful approach to the codebase in order to learn some more about ways that they could build such architectures?
Whilst in the long term (and when working with others) it seems almost always best to go with a codebase which balances well simplicity and expressiveness (no point using Python like Java!) mightn't it be valuable experience, being able to work freely on those mini-projects when younger and without the burden of having to design for those goals of simplicity?
Well, I guess since it's one's own project you can do whatever you want with it!
And I think your point is fair: there's certainly merit in training oneself to write "beautiful" code. But I guess then your goal is simply different, your focus would be on improving your architectural skills rather than finishing the project. There's nothing wrong with that. And of course if you can manage to reach both goals at the same time, you win double.
The secret?
There is none. I'm just better at organizing myself for my goals. I used to go about cool programming ideas like this:
1. Have an initial idea and get really excited about it
2. Clearly see in my mind how I would implement it
3. Think "this can't take more than a week!"
4. Start coding frantically, making sure to have an elegant, modular, reusable code-base
5. On the way, come up with more and more super-cool features
6. Think about every little detail of every feature and make sure implement it "the way it should be done"
7. Give up after two weeks because the project has become overwhelming and despite a massive code-base is not anywhere near a first usable prototype
I think the problem starts at 3. (maybe at 2.) and then gets successively worse all the way down. These days, my workflow looks perhaps more like this:
1. Have an initial idea and get really excited about it
2a. Do a reality-check, find it's probably not worth bothering in the big picture and do something else instead
2b. OR: if I really think the project is small enough, go ahead and give it a go.
3. Think of what the really cool features of the idea are
4. Remove them all and thus come up with a stripped-down, barely even usuable version of the initial idea.
5. Implement it in the most minimal, hackish code base possible: hardcode everything, ints instead of enums, strings are your friend,...
6. Actually finish this bastardized version of the initial idea!
7. Only then decide if it's worth going on from there toward the initial bling-bling idea by means of refactoring and refining or adding more features
Usually, by the time I get to 7. I decide I don't need it - either the version is actually good enough already (meaning the initial grandiose vision was over the top) or it has become clear already that the excitement of point 1. was unwarranted and I probably should have gone for 2a. instead of 2b.
In rare cases, however, I do stay in step 7. and improve upon the initial prototype iteratively. This can even go on for an extended period of time. But even then I'm trying to make sure that I stay true to the same method which can probably be summarized with the following question you have to keep asking yourself:
How can I achieve my goal with the least amount of work?
For me, I've realized it's paramount that I get to a result quickly - that is more important than properties like "with the most beautiful architecture" or "with the best possible UX" etc. You might think that 2a would lead to less stuff done, but in the end I think it actually leads to more mini projects actually becoming a reality.