I recently read Paul Graham’s essay Hackers and Painters and it solidified a few reasons why I enjoy programming for the webs. Graham uses art as an analogy for different aspects of programming. A couple of his points stood out: That programming is not all theory and algorithms as most assume. And that dynamic languages are superior in that they lend themselves to the creative process.
Part of the essay breaks down the misconception that hacking is applied computer science, which implies to program you must have crazy computational theories and algorithms constantly floating around your mind. Instead, Graham paints the picture that hacking is more like art. Programming languages are our brushes and paint and the screen is our canvas.
Along with composers, architects, and writes, what hackers and painters are trying to do is make good things.
The point is web programming is more hands on. Just because it involves computers doesn’t mean it’s all computer sciency. Sure, web programming can be complex. Just to get started, you have to learn three languages. You’ll need a database at some point, which can involve mind bending queries and endless optimization. You’ll need to use design patterns as your programs get massive. And a sea of acronyms and jargon awaits you on the horizon. But the problems you’ll be solving are hardly theoretical. It’s just a matter of practice, not nth power thinking.
All the time I was in graduate school I had an uncomfortable feeling in the back of my mind that I ought to know more theory, and that it was very remiss of me to have forgotten all that stuff within three weeks of the final exam.
Now I realize I was mistaken. Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry.
This is comforting because my little mind has a lot of trouble grasping the abstract underpinnings of programming. Fortunately, all those problems are solved by someone else, which is why Graham was able to forget the theory and focus on more important things and why I can participate.
Another point Graham makes is that languages are best served dynamic. Graham found his workflow consisted almost entirely of debugging. Instead of carefully planning out his programs on paper like he was taught in college, he started in an editor, building and debugging until he was satisfied.
For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching.
He goes on to say that the programming workflow should match other creative processes like writing and painting. Dynamic, interpreted languages lend themselves to this workflow quite nicely. They’re high level and provide a lot of implicit functionality. Therefore you can express what you’re thinking rather than placate the compiler with crufty boilerplate. And you can write and test bits and pieces as you go, just like sketching.
To conclude, if you’re interested in web development, don’t let theory bog you down. Start by learning the tools while building projects. And if you’re interested in programming in general, the web is a great place to be since it gives you the freedom to express your thoughts in the language of your choice.