Many people run side projects, but some people seem better at actually having something to show. The Hacker News community almost certainly has a good number of people who have side projects with something to show so...<p>What are the best strategies (either yours or of people you know) for running a side project so that there's something to show in the end?<p>(For clarity: I'm less interested in the learning outcome and more interested in the material products being out in the world.)<p>What are the best times to work on it? Size of project? Whether to tackle something totally new to you or using your existing skill set?
(1) Pick one at a time to do; don't have ten of them that you start and don't finish
(2) Find time to work on them consistently, either a little bit every day or a big chunk most weekends. What time it is up to you, but you have to get the project done before you start forgetting details.
(3) Face up to the fact that you will have to do things you don't find fun or glamorous to get it "done". For instance, in one of my first side projects, I spent a week (of calendar time, not punchclock time) writing the code, another week getting it to work cross platform, and two more weeks writing the documentation. Had I not done the work in the last three weeks it never would have caught on and gotten a life of it's own.
(4) I think the time frame of 1-4 weeks of calendar time is about right for "small" side projects. If you can turn out small side projects on a regular basis you can certainly take on bigger ones, but even there you should organize the work into "milestones" that are shorter.
(5) As for old skills, new skills, etc. I would say you have to make a decisions for a particular project; using new tech definitely creates risk, and you ought to see where the reward comes from (either "with tool X I should be able to show people something they've never seen before" or "this will be the first really cool project somebody has shown off with X".) Risk management should be practiced with side projects as with other projects -- it is not so bad to add a risk factor if there are very few already, but if there is a lot of risk intrinsic to the project it is not a time to try anything new just for the sake of it being new.
I think it depends on what values raise something from merely something to the level of something to show. One person might feel that knowledge from an unsuccessful project makes the cut while another may consider anything short of a passive revenue stream a failure and a third may seek a portfolio project demonstrating experience with Go-lang for landing Go-lang work.<p>All those are different from projects like Open-Street map which mark success by large world-wide communities addressing global needs.<p>Good luck.
Answering my own question somewhat: <a href="https://www.scotthyoung.com/blog/2013/07/09/side-project/" rel="nofollow">https://www.scotthyoung.com/blog/2013/07/09/side-project/</a>
Instead of using the right tool for the job on side projects I use technologies that will benefit me in my real job. For example I wanted to go fr java dev to nodejs and I used it for side projects that were also used as portfolio