That's true if you broaden the definition of "memorization" to cover all learning, but "learning is necessary for creativity" would not be a particularly interesting thesis.
Expertise is the result of learning from past experience, both in developing an internal intuition for what you're doing and in having past patterns to draw upon. To the extent that experts have simple easily verbalizable heuristics, these are largely post-hoc attempts at explaining their intuition rather than an accurate reflection of how they make decisions.
And, in fact, experts can't even always do that: it is perfectly possible for experts to make good decisions without being consciously aware of why they are making them, and explaining how to make good decisions is a separate skill from being able to make them in the first place. The book I mentioned has a memorable story about a firefighter who thought he had precognition after pulling his team out of a dangerous situation without any specific indicator of the danger, but I figure a more common example is experts saying they did something because it was the "obvious" or "clean" or "better" way to do it and getting a bit flustered when pushed further.
We can see this in action pretty clearly if we look at advice for, say, writing. There is a lot of advice from good writers but just memorizing and blindly following this advice is actively counterproductive. Advice you can memorize fundamentally must lack nuance and context. We can see this clearly because so many different pieces of writing advice contradict each other and because good writers do not follow any of those suggestions with any consistency.
The same definitely applies to programming, which is why we have both "don't repeat yourself" and "you ain't going to need it", and why new programmers trying to apply either rule (or both!) to a codebase inevitably create a mess. What I've found with programming advice is that most suggestions are either actively wrong or too vague to be useful. (By the time you've learned enough about programming to be able to follow the vague advice, you don't need it very much!)
This happened about 20 years ago when they were trying to automate recognizing cancer cells. They showed photos to experienced diagnosticians and asked 'What features do you look for?' They couldn't articulate what they were seeing.
Expertise is the result of learning from past experience, both in developing an internal intuition for what you're doing and in having past patterns to draw upon. To the extent that experts have simple easily verbalizable heuristics, these are largely post-hoc attempts at explaining their intuition rather than an accurate reflection of how they make decisions.
And, in fact, experts can't even always do that: it is perfectly possible for experts to make good decisions without being consciously aware of why they are making them, and explaining how to make good decisions is a separate skill from being able to make them in the first place. The book I mentioned has a memorable story about a firefighter who thought he had precognition after pulling his team out of a dangerous situation without any specific indicator of the danger, but I figure a more common example is experts saying they did something because it was the "obvious" or "clean" or "better" way to do it and getting a bit flustered when pushed further.
We can see this in action pretty clearly if we look at advice for, say, writing. There is a lot of advice from good writers but just memorizing and blindly following this advice is actively counterproductive. Advice you can memorize fundamentally must lack nuance and context. We can see this clearly because so many different pieces of writing advice contradict each other and because good writers do not follow any of those suggestions with any consistency.
The same definitely applies to programming, which is why we have both "don't repeat yourself" and "you ain't going to need it", and why new programmers trying to apply either rule (or both!) to a codebase inevitably create a mess. What I've found with programming advice is that most suggestions are either actively wrong or too vague to be useful. (By the time you've learned enough about programming to be able to follow the vague advice, you don't need it very much!)