I think its good to know both.

Maybe one facet of programming is learning patterns, or approaches so to say. A problem presents itself for the first time and you're baffled. When you solve the problem and come across the same situation, you already know of one way to solve it. This time, you'll most likely find some optimization to your solution which makes it smaller, more elegant, faster, whatever. With time, you know more and more patterns, including bigger and bigger patterns that are made up of - now trivial - smaller patterns you learned earlier.

I'm not strictly talking about design patterns here, there are a lot of common solutions we tend to find and reuse, from below the idiom level up to the architectural pattern level, regardless of what kind of programming language we speak.

-Markus-

Painting is not about putting colored liquids onto a canvas. The paint and the canvas are coincidence; they are merely the tools used to perform painting.*

Programming is not about typing magic words into a computer. Code is a coincidence; it is merely a tool used to perform programming. Programming is in the mind.



* Some postmodernist will probably disagree with me. I'll defend against this with the blanket assertion that "modern" art is not painting, it's putting colored liquids onto a canvas.

So much could be and has been said elsewhere about programming. Paul Graham really glorifies our trade.

I would say that with the best references, most complete docs, and widest aray of very well flushed out examples, it still comes down to sharp intuition and an ability to discern myriads of overlapping patterns. These skills are not something you can "cheat" to gain.

Now, to be fair, there are two distinct approaches to programming. One kind of programmer likes to hop in, and just get it done, writing a stinky pile of hacks that conform to the fractal-like complexity of the other API. He is concerned with making FOO do X and proceeds to do what he can to make that happen. He benefits greatly from every single little bit of reference assistance that he can get, and also benefits from a detailed memorization of how a specific API does things. My old boss was one of these guys. Absolutely brilliant at producing useful work. But, it was shocking how bad he was at designing anything.

The other approach is probably too abstract. This programmer knows that he's already seen a solution to a certain kind of problem before and is mostly concerned with defining what his problems are. An understood problem is a solved problem. He wishes to reduce patterns down to unique atoms that can be applied, so that the program is 100% original stuff for that program, with no fluff from reproducing similar structures everywhere. I've usually been one of these guys... and the problem is....

Programming is very ugly. It wouldn't be ugly if

1) you knew what your program was going to do 100.000% before you wrote a line of code.
2) and you were writing 100.000% of the code that your program relied upon.

But you can't do this. It's too much work. The OS API is ugly because it hides ugly hardware hacks. So far, the best way that I have found to code stuff is to go through the process they teach you in school. Write the ugly hack code, and do it quickly without much concern for the future. Clean it up, abstract patterns out of it. Repeat. This way, you are only abstracting where you actually need to, and your patterns always reflect your real world use for that particular application or kind of application.

Many great programmers use documentation or reference books when they code. Some don't need to unless they get really stuck. It's just all about how much time you put in and how well you know certain topics. A lot of people can program. Some use their memory and some use the references. I guess it's just a matter of how good you are at a certain API or topic. If you are comfortable than you can just blaze through the code.