The Woody Allen way of coding

In a previous post I wrote about the uncompromising artistry of Stanley Kubrick, who produced film classics at the cost of wildly unpredictable schedules and budgets. You can reach for similar brilliance in programming, but you had better do it on your own time or with a generous CFO. There is a different, more workable, and healthier attitude towards our craft. Just keep at it, enjoy it, and don’t worry about making a dent in the universe. Reading Woody Allen’s autobiography over the holidays, indulge me to draw another cinematic parallel with this veteran New York writer/director. Don’t worry, it will also be about coding.

Woody Allen (1935) is one of the most consistently prolific cinematographers in the business. He has written and directed over fifty films over an equal number of years, almost like clockwork and at 85 shows no intention of stopping. He doesn’t approach his oeuvre as a project with a culmination. His business is about keeping busy. He is in it for the long run, if only to act as an antidote to the unavoidable spectre of death and oblivion. But let’s not get into his glum outlook on life here.

Image by Artem Podrez through

Regular output matters more to Allen than consistent quality. For the stubborn perfectionist Kubrick each project took as long as it had to, which meant they took longer and longer. Allen famously compared his livelihood to a convict weaving baskets. This sounds like false modesty at the very least, coming from a four-time Academy Award winner, but it’s obvious that he doesn’t set out to strike gold each time. Even forgiving critics admit that his heydays are long gone. He knows and doesn’t care that inspiration is capricious, but even a mediocre Allen is still a decent picture. He has no ambition to re-invent or outdo himself. He’s known to never watch his own work after completion, which tells you how little he cares for his legacy.

On to software now. Software is not an artefact disconnected from time and usage. It exists in a technological ecosystem and amidst a community of users. You cannot neglect what the customer wants, not even in Open-Source. Today’s market demands go stale as quickly as a loaf of bread, so shipping is a crucial feature. Getting your update out usually outweighs reaching for perfection. Remember Netscape? It cost them their competitive advantage over Internet Explorer when they decided to fully re-write Navigator 4

The archetypal artist pontificates that he can’t imagine doing anything else. It’s a romantic notion, but it gets in the way of a happy and comfortable life. The professional developer should have a more level-headed relationship towards her craft. Do stay put if it hits the sweet spot between what you’re good at, what the market demands and if it pays well. But when those parameters change for the worse it can be time to move on to a different language, platform, or career altogether. To the artist market demand and compensation are secondary, but where’s the fun if nobody wants to use your software?

If you are over thirty-five and still waiting to become a genius, better abandon all hope. Artists, athletes, and many scientists usually peak before that age. Anyway, the definition of genius implies that statistically you are not likely to be or become one. I know I’m not.

The professional is just as much in it for the long run as the artist, but her objective towards exceptional quality is more realistic. Exceptional quality only happens rarely, or it wouldn’t be exceptional. To be in constant competition with your former self is exhausting and demoralizing. Strokes of genius can’t be summoned. You smother yourself creatively if you can’t accept that there will be good and bad days, or even years. Accept that no one can remain at the peak of their profession for decades – except Meryl Streep and Anthony Hopkins.

Finally, there’s a compelling reason why making software with the artistic mindset makes no sense from a utilitarian perspective. It’s the stale bread metaphor. You can frame version 1.0 of your painting and with luck it will only increase in value. You can run vintage video games and VisiCalc are fun for nostalgia’s sake, but they are anachronisms in today’s ecosystem. 

I have left behind reams of legacy code in the projects I worked on over the last twenty years. Most of it has been scrapped long ago or refactored beyond recognition. The best I can hope for is that it didn’t cause my successors to curse me. I have also embarked on many hobby projects. I call them hobby projects not because of any substandard code cleanliness; it was good code. I once spent two weeks of the Christmas holidays refining my Hibernate-killing database DSL in Scala. Then my taste for Scala subsided and I haven’t returned to the code since, which is lethal if you want to make a credible impression in Open-Source. But I just wanted to get better at Scala, not kickstart a successful project and certainly not turn it into a business – I know I don’t have what it takes. Yet I enjoyed every minute of weaving that basket while it lasted.