I enjoyed your article and wish I had understood the "partial progress" concept when I was doing college math. It would have helped a lot, and would have been a small stretch, since you've described hacking, troubleshooting, and prototyping, which are important but sometimes neglected engineering techniques.
In creating his first applications, my son is happily accepting failure as he hacks his way to get his apps working through trial and error. He focuses on part of the problem, beating on it with no fear of breaking something or trying something he knows probably won't work, in the off chance that it will. I think he gets this from playing Zelda, where you have to lose multiple times in order to figure out how to conquer a dungeon, and then repeat this for all the dungeons necessary to obtain the ultimate win.
If "partial progress" sounds a lot like hacking, then the divide-and-conquer part of it describes troubleshooting. And the "corollary", where you try a technique even though it can't possibly solve the problem completely, sounds a lot like prototyping, where you build something that works, but at some degraded level, to get a better understanding of how you will provide a complete solution.
It sounds like there are two lessons here: realizing that you CAN divide most meaningful problems into more than one or two parts, and then understanding that you must trying several (many?) approaches (with perhaps many failures) to discover the lines that separate those parts.
The last step, to attempt to optimize the solution by finding ways to combine the solutions to few as possible, is where we get tripped up, because I think a lot of us unwittingly try this first
. We grow up being taught that there is only one correct solution to a math problem, or if there are several, there is only one "right" solution. Even the standardized tests drill this into us. They present several options that have varying degrees of correctness, but you know you get no points for choosing one of the semi-correct answers, so you better darn well focus on getting the answer right the first time.
Convinced we must "get it right" we beat on the problem and fail, not realizing that an initial Frankensolution bolted together from piece parts is actually REQUIRED to help us understand the underlying mechanisms and gain the insights necessary to find the more optimal solution.
Thank you for pointing this out. Great article!