Paul Graham published a great essay on the parallels between hackers and painters. I find it funny that this would come up on the net this week as I was pondering some of the same things in the past few weeks, since I visited the amazing Da Vinci show at the Metropolitan Museum of Art this year.
I’d like to add a few points to Paul’s discussion on this, however. Unlike other great forms of art, great programming is more appreciated for its risk taking at the time at which it happens. For example, if you visit the Musee D’Orsay, which covers the full range of 19th century art, you come to realize that the paintings that received the most prizes in art competitions were not the ones that took the most risks. They were generally more bland and the more daring pieces were often the cause of much controversy and shunned by the “people who mattered”. In the same fashion, some of the greatest books in history have had very rough beginning, often being recognized as masterpieces only years after their author’s death.
In the programming world, however, a great piece of code is highly praised for its ingenuity and its risk taking. Large leaps have been made over the past decades by people who essentially figured that working within the system might only achieve incremental improvement but working outside of it could generate something much more interesting. If you look at the development of the commercial Internet (and of the open source movement), it is this “let’s try to do something more” that has engendered some of the biggest leaps.
The 90s were an interesting time in that people looked at the Internet and essentially allowed for day jobs to be created so that people could explore possibilities. While much money was tossed at people trying to do things that wouldn’t work (pets.com, anyone), the truly innovative companies (Amazon, Ebay, Paypal) took large leaps of faith and were rewarded for them.
While the leap of faith in terms of the idea is prized, some other parts are not. In my early days as a hacker (and by hacker, I mean someone who toys around with code, not someone trying to break into systems), tight code was the norm. A large part of the reason for this was the limited amount of space we have to play with. As a kid in the early 80s, I was playing with computers where RAM was calculated in Kilobytes, not Megabytes or Gigabytes and, as a result, my friends and I were always trying to get more out of each byte of code. As memory availability increased, it seems that people became more careless in their programming, often wasting useful resources in terms of CPU space and memory space. This skill, nowadays, does not seem as prized as it used to be. The same is happening in terms of web development, where sloppy usage of XHTML is forcing us down a path of more bandwidth for the bang. To me, the real beauty of a lot of code lies in the fact that more can be done with less. This, however, seems to be a lesson that many have not learned.