|Perl: the Markov chain saw|
I would take this a step further and suggest that it is all algorithm analysis. Not so much analyzing the data, but knowing what to do with it - Knowing how to solve the problem.
Take, for instance, a recent example from my "SpareTime" file. I watched some family members play a game of boggle and thought, "Hmmm, I bet I could write code to solve an arbitrary sized board, and do it using both recursion and without."
The hardest part was analyzing how you actually solve it (match words of minimum length to a known dictionary(s) given certain path and adjacency restrictions). Once I realized how it was done, the code came out in an afternoon. It was really a matter of analysis. The data (in this case a 6x6 board of random letters) was not as important as the structure and method.
HOWEVER, if I didn't know how to use lists, recursion and references, didn't understand how to streamline my code and optimize, I'm pretty sure some of my first 8x8 attempts would still be running on one of my servers somewhere.
I'm going to have to agree with Steve Lohr on this one, when he observed that, apparently, knowing how to code leads one to better problem solving, and vice-versa. They are partners in this game. I don't really think one goes without the other. Strong problem solvers make strong coders, and weak, weak IMHO. I think a certain level of problem solving and technique can be learned, but I think it's one of those quirks, either you have it or you don't.
"There are a certain percentage of undergraduates - perhaps two percent or so - who have the mental quirks that make them good at computer programming. They are good, and it just flows out of themů.The two percent are the only ones who are really going to make these machines do amazing things. I wish it weren't so, but that's the way it has always been."