Advice: Don't Do It Right

I remember when, years ago, I was at elementary school I got an important advice from my grandmother. Once, checking my homework she noted that I should pay more attention and care to it, despite the illusion that doing it faster saves me time. The problem was that I didn’t want to do homework – it bored me – what I wanted was playing video games, taking a walk or watching some Discovery channel movies about science and hi-tech. With homework I pursued the sole purpose – to get rid of stupid exercises in arithmetic and Russian as fast as possible and get to worthy things. Obviously, this impacted the quality, which was difficult not to notice for my granny and thus she tried to help and motivate me to do better. She used quite a powerful argument saying that everything that’s not done right will have to be redone later. So being more careful and focused from the beginning I will be able to avoid returning and save a lot of time for great things even though this might not look this way at the first glance. I did grasped the idea and, although sometimes I failed to focus on boring stuff giving way to mistakes, I kept in mind the notion that one should take care to do everything the right way so that they don’t have to come back to it long after.

Still, now it seems to me that I got the advice wrong and took it too far, which produced a very bad side effect on the way I work. What I mean is that when trying to create something that is important and interesting to me I become obsessed with the quality of the thing long before it even begins to emerge. This way I quickly find myself in exhaustive search for the right ways to implement every tiny piece of what I am trying to accomplish and during its course I usually can’t allow myself to sit down and build something little and potentially dirty, because I remember this is a waste of my time. One may think that is great and helps me create nice and wonderful stuff, however the reality is harsher. This chase for perfection giving birth to the fear of dirt actually raises a stone wall between me and long waited moment of achieving my goals.

The reason for this is that creating means learning. Learning, in turn, can’t take place without building dirty things and making them better – as far as I know, there isn’t such a thing like a direct way to mastering something without making a stupid mistake or two first. It took me long to accustom myself with this idea, see how it hampers my own work and learn to spend less time on weighing infinite number of alternatives, throwing them away and finding and weighing some more, again and again. I have many times faced this problem when writing posts for the blog, but eventually I have developed a habit of quickly hacking a couple of dirty sketches without concerns of the language and other aspects of quality. Doing these I literally push myself to leave white spaces and ignore the fact that some of my phrases feel Hulkish at best – this way I can proceed knowing that later, when I see the full picture clearly, I will return and make the ugly parts polished and shiny. Such an approach saves me a lot of time, which would otherwise be wasted on searching for words that are yet to come and expressing the ideas, which I realize only partially. In fact, there is nothing bad or inefficient in producing a thing that lacks elegance or even correctness on some stages of the process. Moreover, doing so doesn’t hurt the quality of the final product at all, as long as one remembers to return this debt later.

Fellow coders might have guessed that I learnt this approach through programming. Kent Beck’s ‘Test-Driven Development: By Example’ book was the first thing to introduce me to the idea condensed in the words "first make it work, then refactor". While Kent deals mostly with the low level of code in the context of solving a specific bit of a problem, the advice is also applicable to most other levels and aspects of the software development process. I find it particularly helpful when working with new technologies – languages, frameworks, libraries and whatever else: in many cases spending a lot of time on trying to figure out the abstract right ways to use the tools turns out to be a major waste of resources of any kind. On the other side, actually taking what you have and building something, maybe so ugly and stupid that even stackoverflow won’t bear its presence – but working, provides one with better understanding of both means and goals. Honestly speaking, I rarely realize what I want from a particular tool until I actually try to use it some way, thus the chase for perfection ‘from start to end’, although may produce something nice, most likely won’t lead me to what I wanted. Moreover, there usually exists a chance that I will fail to create anything meaningful at all.

Perfection requires major investments and a firm basement, which is to be built from something common and dirty. In the end, it is quite difficult to claim a cathedral a piece of art while it is being constructed from stone, steel, cement or clay, but no one will remember what its naked walls and empty windows looked like once it is finished. I believe that years ago my granny didn’t want to make me do my homework perfectly correct right away. What she meant was that I should start whichever way I like but not stop until the thing looks beautiful.