The Law of the Draft, or What it Takes to Write Good Software

by Dmitry Kirsanov 9. April 2012 16:41

Moses (brings 10 testaments), painting by RembrandtNot long ago one acquaintance of mine, an HR manager, said that she doesn’t believe that I’ve deleted a small document I’ve created a year ago for my own needs. A list of 20 questions for beginner software developers. I wouldn’t ever consider it an asset.

She couldn’t believe I was able to delete so important and useful thing.

I tried to recall what else I’ve either deleted or abandoned during my life as professional, and who would consider THAT as an asset. And the scale of what I’ve seen in my vision led me to obvious, but perhaps unwritten law of software developers. The law of the draft.
In short, I believe that you should always have at least one project ongoing, and it shouldn’t be anything related to your job, as well as you should not consider to obligatory release this project.

Here is why I think you should follow this rule, unless you already do:

First of all, your experience is your asset. Not the one everyone sees, but the most useful one – which will make your future projects more effective. Having done that before allows you to be more productive, having more time for doing what others wouldn’t have enough time for, under the same conditions. The truth is – even if you are indispensable, brilliant professional, the most of the time you are not, you are just like others. You are brilliant in that tiny bursts of pure genius which makes you what you are. Ideas and conclusions that you come to in different situations, and sometimes these ideas and conclusions need time to form.

The draft projects are what calls for your inner genius to produce – ideas and conclusions, and that boosts your creativity and insight. The “draft” project doesn’t have many constraints you may have in “real” environment. No deadline, which means you may have more time for brainstorming, no opinions of project participants, no innovation-blocking decisions, no superiors who make decisions according to their limited knowledge. You are on your own, and you allow that “own” to grow and experience situations which would be treated as impediments that could jeopardize “real” projects.

What you do, at it’s best, is an art. The problem is – if you are told what to do, it’s not an art anymore. It’s a job. Usually the one which doesn’t give much time and space for creativity. But in order for your genius to survive, to not let that fire to fade, you must practice. If your job does not involve creating art, for example when you get precise instructions from your superior and the better is considered the enemy of the good, you still can and should practice on your own, unless your life plan is to follow instructions.

The same is for the purpose of that imaginary project – it should change something for user. If the only user is you – that project should change something in your life, your work or whatever. There must be the purpose. It should be innovative, at least at some degree. You could copy the existing solution but add something that you would like to see in it. For example, once I’ve created the exact copy of the well known web service to send large files, but added the possibility to use my own servers at will. Was that time consuming? Yes. But it worth the effort.

If Depeche Mode would release every track they shelved out, some of these works would be considered genial by most of their fans. And they released a lot.

If Rembrandt wouldn’t practice almost every day of his life, would you be able to mention those few famous paintings of him that you know of? Would they reach Louvre? Would I mention him in my blog post?

Since I am talking about art here, the same reason – the art – is why the side project of yours should not be inspired by, or connected to any ongoing project from your current job. Because that will be like the flight in aerodynamic tunnel – which technically is a flight, but only technically.

And the reason to not aim at release is different. When you are aiming to release your project, you sacrifice your creativity to the deadline. You must release, sometimes you must release often, and so you can’t constantly add features, change design, reshape the underlying database or make any other dramatic changes – because that would ruin existing installations. When you have 3 days to deadline and 3 of them will be consumed by coding, you won’t have another 3 for brainstorming.

So don’t aim to release, don’t allow the fear cut the wings of your creativity, and suddenly you may find out that you can share that toy of yours with the world. You may realize that you’ve just created a perfect gift to the world, which will boost both your career and reputation. The latter is the key to the next level.

blog comments powered by Disqus