The perfect is the enemy of the complete
I heard this advice a long time ago, and it is even more relevent to me now than before. Originally it meant that I should finish the work I was assigned, and not waste time on incosequential details. Now that it means choosing what work I will do, how I will do it and what "complete" actually means, this advice has become even more relevent as well as much more challenging to follow. I have spent the last two weeks months putting together this portfolio website, and it is clear to me now, how far from complete any of my projects are.
There are some inexplicable omissions. There are several features in my code that are complete, and good looking, but can only be activated by editing the source code and recompiling. I just never got around to creating an interface for them. In my raytracer, crtrm, the only way to change a material for an object was to edit the source. The Javascript version had bizarre projection vectors that made any rendered image into something that looked like a badly tuned television. The map viewer, Entirety, did not in fact view maps. And several other features were moderately broken, only requiring some small tweaks to get them back in working order.
So that has been my goal for the last two weeks months, putting my house in order. For the most part, I have managed to stay on track. But the original situation is intolerable. Some of that mess is explicable. Hobby projects have to be interesting, or I would never work on them. However at work, we always had the rule "don't break the trunk". The trunk branch of our source code, and in fact all the branches, should always compile correctly. And have tests. Which has the nice effect of making sure that they are always ready to demo with less than e.g. 1 hour's notice.
Outside work, it's hard to put together rules for myself, because each situation is different. I should focus on completeness, but at the some time, some new features are necessary. I want to put lots of screenshots on my website, and my current method of "taking a screenshot then cutting out the picture in the GIMP" is taking way too long. Adding a "save screenshot" feature to my programs is a good use of my time(done using SOIL). And if the development blogs and guides that I read are correct, I should probably add a "post to facebook" feature, so I can get working on my personal brand. I'm not so happy about that, but it is part of completeness, I guess. But maybe being on twitter is less than perfect?
After a bit of thought, my guideline for my current work might be "it's not finished until someone else can use it." Ideally that would be a full release, with a convenient installer. And with good documentation and usability. People (reasonably) don't like to explore software anymore. Either it works the way they expect, or they move onto the next one.
I'm looking forwards to getting this site up to a standard where I can be in a job interview and say "Yes, I have experience with that. Let's open up my website so I can show you...". Still, it's so much easier and appealing to go and reorder my links page, or adjust the indenting in my code, than actually do things that make progress. Making safe, minor changes is always more appealing than taking on the big problems, and since those minor changes include frittering away time writing blog posts, instead of making cool things to post about, I'll stop here.
PostScript
While I was writing this, my friends asked me how my android app was going. I had written a quick program that scraped wikipedia for the locations of railway stations. It would pick the closest station, and display a giant arrow on the screen, pointing to that station like a compass. That's an even higher level of "letting things slide", that I need to avoid.