Programming is a subject most often lumped in with engineering or science, and there are countless books dedicated to writing better code, but is this a good approach? To me, it seems much more reasonable to understand it as a form of art.

Does it matter? Yes, I think it does. I believe that this distinction is important, and I believe that many other programmers agree with it. I also think that it affects how we view and hire programmers, and, ultimately, it greatly influences the productivity of software development in many companies.

Art?

So, why is it art? Writing good code does not come solely from studying books and lectures – like other forms of art, it requires practice. Books and lectures can teach you the theory and the technique, but not the art. To be a truly great programmer, you need years of painstaking practice, where you constantly challenge yourself into doing things you’re unfamiliar with – just like other forms of art. You can study music theory all you want, but without lots of practice, you’ll never be a great composer. Peter Norvig makes a compelling point that mastery of programming, like other arts, takes some ten years of practice.

This opinion that programming is art is hardly radical or new. Donald Knuth‘s “The Art of Computer Programming“, one of the most important computer science books, alludes to the idea in its very title. On an essay on the title of the book, Knuth says:

Our discussion indicates that computer programming is by now both a science and an art, and that the two aspects nicely complement each other. […] We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak about the state of the Art.

Knuth is not alone. In that same article, he quotes another great computer scientist, Edsger Dijkstra, who, while not spelling it out, clearly seems to share that vision. Harold Abelson opens MIT’s legendary “Structure and Interpretation of Computer Programs” 1986 lectures (based on the also-legendary book by the same name) with the following statement:

“I’d like to welcome you to this course on Computer Science. Actually, that’s a terrible way to start. Computer Science is a terrible name for this business. First of all, it’s not a science. It might be engineering, or it might be art, or we’ll actually see that computer so-called science actually has a lot in common with magic.”

So why are people so reluctant to accept that it’s art? It’s obviously not traditionally listed as a form of art, but a century ago, neither was cinema. The biggest stumbling block might be that programming is a sort of invisible art – the customers, who ultimately pay for the work of the programmers, never get to see the actual code. If you hire an illustrator, you can see his portfolio and judge his work, or if you hire a musician, you can listen to his compositions and performances. In that sense, the art produced by those can be directly experienced by the client.

In contrast, the art of programming can only be experienced indirectly, by the performance of the software it describes. Unable to understand the actual program, all that the clients can do to judge the work is to see whether it works correctly or not – which is, of course, of paramount importance, but masks the true costs involved. “Works” doesn’t mean that it will always work correctly, that it will always have good performance, or that it will be easy to maintain in the future. In the end, the client has no easy way of knowing how skilled a programmer is, and handling a project to an unskilled team is a fabulous way to overrun the budget.

Not All Programmers are Made Equal

This view that programming is a mechanical process, that its output is either “correct” or “incorrect”, without conception of a vast gradient of quality in-between those is, in my view, dangerous. The most dangerous misconception is that all professional programmers are roughly equally skilled. So, just as you’d expect any IT specialist to fix your networking issues in about the same time, or any medic to diagnose your symptoms, or any engineer to be able to design a bridge within your budget – with perhaps a few select few among those capable of doing a slightly better job – you might expect all programmers to be able to turn your requirements into a decent quality software.

Yet, time and again, studies show that the difference between average programmers and the best programmer is enormous. It’s difficult to evaluate the actual quality of the code generated, but if you measure efficiency by how long it takes to fully develop the software (including any necessary analysis, testing and maintenance), top-class programmers are up to 20 times more efficient than average ones (see: Coding Horror). Let that number sink with you for a while. It means that a single high-class programmer can replace twenty average programmers. This sort of difference in skill is unheard of in most crafts – but it’s not unusual in art. You wouldn’t expect a medic being twenty times as good as another, but what about a musician? A painter? It seems reasonable, to me.

Similar claims are made in The Mythical Man-Month (the classic book on software engineering, and managing the development team), chapter 3. The titular essay within this book also elaborates on why it’s better to have one good programmer than many weak ones, and, in fact, better in general to have as few programmers on the project as possible. It seems to me that, if the skill difference is so great, and so relevant, then we do not pay enough attention to this fact, and the unspoken assumption that programmers are roughly on the same level is probably responsible for enormous amounts of money being wasted in companies all over the world every year.

On Hiring Programmers

I believe that this mentality is most clearly seen in the job requirements for most companies. Most will expect you to have formal education on the area – graduation, at least -, but do not ask you to provide with samples of your earlier work, done privately for your own purposes. Why? If a programmer truly loves programming, and has had time to accumulate experience, then he must certainly have a number of projects under his belt – and probably many made without being hired to do so. In my opinion, that’s amongst the best ways to evaluate how good a candidate programmer will be.

Expecting that a diploma in computer science is guarantee that the candidate will be competent (or even adequate) is naïve at best – not only it’s not a guarantee of any sort of competence, but there is data suggesting that the majority of those are unable to make even the simplest of programs. In my opinion, graduating in computer science can teach you many things – but nothing that you couldn’t have taught yourself with curiosity, love for the subject, and Google. There will always be a place for formal education, but it should not be thought of as a requirement. Writer Isaac Asimov said:

“Self-education is, I firmly believe, the only kind of education there is”.

The situation is perhaps best illustrated by taking the title of this post literally. Imagine that, instead of hiring programmers, you were hiring artists. Say that you want some concept art or illustrations for an important project. Two artists show up for the interview. One of them presents you a wonderful portfolio, full of beautiful and inspirational pieces of art, but admits that he never attended a single class beyond high school. The second has no portfolio to show you (though he assures you that he has done some “pretty similar” stuff on his last job), but he has a diploma in some art major by some prestigious university. Without thinking twice, you hire the second, telling the first that while his work is “impressive”, they’re not interested in hiring people without a diploma.

Does that sound absurd to you? In my opinion, it’s exactly the same for programming. And if you are the kind of manager who will do the same when confronted with the above situation, but when hiring programmers, then it’s my belief that you are doing your company a huge disservice.