[kragen]

I think it's potentially dangerous. When I was first learning to program, there were a lot of things I couldn't figure out how to do. Then I came across an algorithms textbook (Algorithms in C, by Knuth's student Sedgewick) and it explained how to do a lot of things I had never been able to figure out how to do before, and with beautiful code. This was a wonderful revelation! I then spent a lot of time studying algorithms.

Unfortunately, I didn't learn how to program! I thought that what I was missing was knowledge about algorithms, and that was occasionally right but mostly wrong. Worse, algorithmic textbooks bias you to look for the one weird trick that makes your apparently complex problem simple. But usually that trick doesn't exist, and when it does you usually have to solve the problem the hard way first before you understand the problem well enough to find it. The process of debugging, refactoring, optimizing, and testing that gives rise to the final polished form of a program cannot easily be inferred from what remains. Books like The Practice of Programming and Code Complete were much more helpful, but you can't learn to program by reading books, any more than you can learn to play baseball or win lawsuits by reading books.

I did eventually learn to program pretty well, though I'm not yet a master of the craft like Knuth, Jeff Dean, Rob Pike, Walter Bright, or Norvig. I did it largely by a practice described in this interview: writing new programs every day. I also learned a lot from pair-programming, which taught me both to read other people's code (we had collective code ownership) and to write code others could understand. My main obstacle was not ignorance but perfectionism and lack of practice.