I have a friend who is an artist that spent the last 10 years working on his painting skills. I observed one interesting parallel between developing skills as a painter and as a programmer based on conversations with him.
Beginning painters tend to get overly focused on very small details without having a good understanding of how they are bringing the painting as a whole together. They spend too much time on these details, whereas advanced painters are able to move very quickly with faster strokes. It's pretty amazing to see a painting where the strokes don't make sense when you look at them one-by-one, but the overall effect truly reflects something from reality.
I found this to be true also with inexperienced developers. We focus on the latest trends, micro-optimizations, coding styles, and "small" details that are easier to master -- yet we struggle with the bigger picture things like delivering a product quickly.
Kind of like the saying "you can't see the forest for the trees". (You focus on the incidental details, but not the larger purpose)
On a slightly different note, I have several friends who are writers and I have found programming to be very similar to writing a novel. You have to construct a coherent world that "compiles", e.g. the characters interactions are consistent and make sense; each character has a role in the story like a component in a program would have; simplicity and directness tend to be more effective than ornateness; small changes in one part of a dialogue can have cascading changes across the rest of the storyline, much like a refactoring gone wrong.
Some years ago now, I came upon a lovely essay entitled "Hackers and Painters†". Here is how it begins:
When I finished grad school in computer
science I went to art school to study
painting. A lot of people seemed
surprised that someone interested in
computers would also be interested in
painting. They seemed to think that
hacking and painting were very different
kinds of work-- that hacking was cold,
precise, and methodical, and that
painting was the frenzied expression of
some primal urge.
Both of these images are wrong. Hacking
and painting have a lot in common. In
fact, of all the different types of
people I've known, hackers and painters
are among the most alike.
What hackers and painters have in common
is that they're both makers. Along with
composers, architects, and writers, what
hackers and painters are trying to do is
make good things. They're not doing
research per se, though if in the course
of trying to make good things they
discover some new technique, so much the
better.
I'd have to disagree; I view programming as an art similar both to music composition but also very much like painting---this may require expanding your definition of panting from the classical sense to the Dada sense of found object sculpture as a form of painting/making-your-own-paint (can't find citation, but there is a good Marcel Duchamp paper about making your own paint I was trying to find---but late for work!).
Beginning painters tend to get overly focused on very small details without having a good understanding of how they are bringing the painting as a whole together. They spend too much time on these details, whereas advanced painters are able to move very quickly with faster strokes. It's pretty amazing to see a painting where the strokes don't make sense when you look at them one-by-one, but the overall effect truly reflects something from reality.
I found this to be true also with inexperienced developers. We focus on the latest trends, micro-optimizations, coding styles, and "small" details that are easier to master -- yet we struggle with the bigger picture things like delivering a product quickly.
Kind of like the saying "you can't see the forest for the trees". (You focus on the incidental details, but not the larger purpose)
On a slightly different note, I have several friends who are writers and I have found programming to be very similar to writing a novel. You have to construct a coherent world that "compiles", e.g. the characters interactions are consistent and make sense; each character has a role in the story like a component in a program would have; simplicity and directness tend to be more effective than ornateness; small changes in one part of a dialogue can have cascading changes across the rest of the storyline, much like a refactoring gone wrong.