The part the author is missing completely is where, as a programmer, you find the problems you need to solve, and you analyze how your answers/solutions interac

The part the author is missing completely is where, as a programmer, you find the problems you need to solve, and you analyze how your answers/solutions interact. A program is an interwoven web of answers, often reformulated, not a list of verbatim answers. What you do is not the dozens of quick things you can look up on the 'net. What you do is assembling a larger thing, and that is where your skill comes in. To go back to the librarian analogy: You're not looking up a bunch of answers, you write a book (or at least the outline of one) for a new topic. Part of that, unless you can afford a research staff, is looking up a bunch of answers, yes. But it's not what you do for a living by a long shot.