1) The book How to Design Programs. Its main point: the shape of data determines the shape of functions. Northeastern University has a good course on this principle. There are several types of data, such as atomic values, constrained values, lists, and the functions for dealing with them follow the "shape" of how the data were defined.
Recursion can also follow this pattern because data can be defined recursively, such as with binary trees and linked lists. Obviously, recursion is not limited to recursively defined data, but it helps to see the relationship between functions/methods and the data they operate on.
The book and the course also discuss how to abstract general patterns from concrete instances, such as "filter", "map" and "fold".
2) Once I saw that function "structure" can follow the structure of data, I looked at the structure of functions that operate on graphs, trees, arrays, greedy problems, dynamic programming problems. There is usually a structure involved.
To get at the structure, I abstracted the details to get at the "elements" of the function and the data it operates on.
Here's one pattern: for each element of data input do something with that element
Basically all algorithms follow this pattern. Replace "do something" with a transformation, a summation, a "map", filter, fold, etc. Replace data input with tree, graph, array, etc.
3) For dynamic programming, I studied the approach used in "Optimization" courses, often taught in the context of business. In that context, DP is not taught as "finding the subproblem", but as a multistage decision process. I found this very helpful.
Lastly, even though receiving material rewards is nice, re-framing motivation towards contribution rather than receiving can mitigate disappointment in any endeavor in life.