At last, I managed to make it through "Art of Unix Programming" by Eric Raymond, thanks to a long train ride and an extended weekend. It's a very relevant book for all kinds of programming work, despite the rather exclusive title, and I will make a post about it soon (the draft is ready, still working on it), but one of the central themes mentioned as a part of the Unix philosophy connected really nicely to something else I was preoccupied with for a while now. Among the "supreme principles" of the Unix methodology, there is a principle called "Rule of Optimization", which is that a programmer should "Prototype before polishing, get it working before you optimize it". When you start working on a software project, it is difficult to know beforehand which parts of it are going to be difficult to write or decisive for the architecture of your code. Instead of relying on preconceived notions and prematurely spending unnecessary amounts of time to get the perfect design or the fastest algorithm for a routine which will run once when a program is called, it makes the most sense to get a prototype working with sample input, discarding edge cases, error handling and such. As Raymond points out, another well-known slogan in this direction is the ductus in extreme programming that you should "Make it work, then make it right, then make it fast".
As I understand it, the Rule of Optimization tells you to first make something, and then make it good; get it going first, and then get it right. The value of this piece of advice is not limited to software. Often, when you set out to build something, you don't know what's going to be difficult; if you try to get it right the first time, you will be prettifying and polishing the wrong parts, spending your precious time in the wrong places. The net result will not be that something takes longer than it should —this is usually what happens in the end anyway. More importantly, you simply won't be able to get anything finished, or be able to share it with other people. There is just a certain amount of time and energy you can put into an undertaking, be it a single blog post or a small software project, before losing interest in it and moving on to something else. Build something, see what works and what is missing, and then re-build and/or improve, if it's really worth it.
The idea that you should initially disregard perfection and aesthetics runs against the mill of what we learn through the homework-oriented pedagogics of the public school system. In school, you get points not for making something good enough to later improve on it, but making it as good as possible in the first try. You can't just go up to your teacher with a half-finished whatever-your-homework-involves and ask him/her "what do you think can be improved on this thing?" or ask one of your classmates "would you have a use for this thing here, and if not what is missing?". The deadline defines your project; whatever you get finished till that deadline is what that project is. The prototypical statement of this "philosophy of craft" is the parental saying “If a job is worth doing, it's worth doing well”. What we can call the "worth-doing-well approach to project management" disregards the social aspect of the construction of useful things: When you grow up and undertake things on your own incentive, the 'finishedness' of a project is not measured by whether it is enough for a passing grade, but by numerous complex factors which unfold in a social environment.
Another thing that gets lost in the worth-doing-well approach is, as anyone who has gone through school education knows, the fun factor. You are not supposed to enjoy whatever you are doing in school; it's hard drill that prepares you for the future, not the kind of activity you are supposed to enjoy. After a certain age, though, and a certain amount of education, you do tend to search for fun, even in work. With time, you develop a heuristics of what will be fun for you, and gravitate towards those things. Getting things finished means a lot of discipline, but how can you decide where you want to commit that discipline? The only reliable way of finding out is trying things out, accepting that you will not be able to finish every project you start, and abandoning those projects which turn out to be unsatisfying in one respect or another. But this is the fun part anyway; the trying out, poking here and there, and finding out which combinations are possible.
As Niels Bohr once said, the opposite of a profound truth may also be a profound truth. Now, "if a job is worth doing, it's worth doing well" is not particularly profound, and talking about something really profound would be against the gist of this whole post, but the opposite of it has simply been said, and it rings much more interesting than the original: "If a thing is worth doing, it is worth doing badly". Clay Shirky attributes it to William S. Burroughs, whereas some people on the interwebs point to Chesterton. The charm of this simple inversion lies in its pointing to something about doing and building that the original obscured: Most of the time, it's not about getting it perfect or right the first time, but improving and creating opportunities for further combinations. Looking from the authorial point of view, it's not the eventual discovery of a profound idea that should drive writing, but the probing and poking. It's this probing and poking which is the most fun anyway, and whoever enjoys this, will improve even while doing it badly, of course unless he shies away from doing imperfect work because he is scared of not making the grade.
Also, this reversion of the worth-doing well approach is nicely suitable to the world of internet, which is one of abundance -- this is the reason Shirky is so fond of this saying, and mentions it also in Here Comes Everybody. Since there is so much stuff out there, and it reaches so many people at the same time, many of whom are content producers themselves, the chances that a piece of text or software (or music or video...) will find an audience, no mater how small, much higher. So do it and put it out there -- on a blog, on github -- and let the others decide whether it is worth attention and improvement.
The dictum "what is worth doing is worth doing badly", if I were to judge from the quality of my own posts until now, is a rather apt slogan for this blog. I hope I find a good saying about concentration and persistence before I get bored or just distracted.