For solving problems you need problem solving skills, abstraction and an ability to express that. This comes by experience.
Using your own words from comment 41563505 above, I don't see how you can make that argument. You can get by without any creativity and create functional programs. But problem solving often requires some creativity.
I take a look at the development of languages, from C where you can accomplish the same thing in hundreds of different ways due to the raw pointer and things like unions. Someone creates a new language trying to make the language match a particular domain problem, and it becomes all the rage.
OOP brought with it a huge playground in which you could work yourself into an inherited hole, or cleanly re-use code from a base class. Skipping straight to MVC, all of the good ideas around Rails and Spring were essentially "solved problems" which became formalized in the framework. Using C# under MVC implements those "solved problems" in ways which were not clear, or often not even possible, in .NET, without creative workarounds.
Here is the introduction to my programming style: Expressive Programming, which I define as "expressing your intentions so the code is clear." No obfuscation in clever re-use of generic code, unless it is clearly generic and can be clearly expressed. No hiding behind "magic" constructors or members that go off into the database. And the point is, choosing the right solution when a handful would meet the same requirement, requires creativity.
As I said, you can brute-force that by learning every design pattern and debating each one, and then through experience it becomes more clear which is the best path to take. It becomes intuitive, and eventually it just "feels right". If you decide that your domain has a single design pattern which fits the product, and slavishly follow that pattern even though it might not make sense, you are coding without creativity. And your code will most likely have an unmaintainable steaming pile which is inherently change-resistant.
Fixing a bug to adding a small feature inside an existing codebase can be free of creativity, which is why OP fears going the maintenance route. It's boring, and going through someone else's code which you may not even fully understand is not fun. It can also be very creative, where you find the most Goldbergian workaround to avoid changing critical infrastructure and reduce the amount of testing that needs done.
To find a proper balance is an art.
OP also talks about "training". Training is where you read a book or attend a lecture and do exactly what it says. Learning is when you take the same information and apply it judiciously. You can certainly implement a flowchart to decide when and how to break out of the mold. But a person who is a creative problem solver instead of an algorithmic one may come up with the novel approach which soon becomes a de-facto standard such as MVC, Or variations such as MVVM.
OP can be "trained" to do the same repetitive thing in things like circuit design or physics simulations, which is valid. Or OP could learn, generalize, and apply that information to new scenarios in the form of continuous training.
As much as we know about creativity, it could very well be defined as the nature of having been exposed to enough variations that a problem can be solved intuitively, without going through the intermediate steps of evaluation. But there is more evidence that creativity is simply a different way of thinking entirely. The fine line between creativity and insanity, where insanity can be very roughly approximated as "not thinking about things the way most people do."
