That remark from L. Torvalds is, I think, about how to approach problem solving. I'm sure he does have some opinions about code style and organization, but I fe

That remark from L. Torvalds is, I think, about how to approach problem solving. I'm sure he does have some opinions about code style and organization, but I feel that they would be shelved under a different conversation. Programming is ultimately about reading and transforming data. When presented a problem, the bad programmer (presumably not well versed in DS theory) thinks of it first in terms of "steps to reach a solution". Whereas the more skilled programmer is able to identify which set of DS is a good match to a specific problem. That is, which combination of structures allow for an efficient access and manipulation of the data in the context of the problem at hand. The implementation then stems from that insight. Obviously this skill is mostly valuable in performance critical code, which the bulk of our trade generally doesn't intersect with. And in an age of fast processors and abundant memory, it's common to see O(N) data structures applied to O(1) problems and barely anyone notices the cost. Thus keeping us in the comforting illusion that we're better programmers than we actually are.