I think you're talking about engineering, because programming is definitely about trying until it works.
I think you're talking about engineering, because programming is definitely about trying until it works.
For example, trying to iterate on regexen to see how well they validate credit cards on your shopping cart form is at a different level to say, trying out a new database system. The former can be undertaken in a desultory way more easily than the latter--and therein lies the trap. It's easy to generate a false sense of progress, seeing code being output and test cases passing, all the while without really understanding or learning anything about the code or the problem at all.
Precision understanding of the mechanics of coding, on the other hand, free you to concentrate on higher problems. You don't need to play whack-a-mole with locks and semaphores to eliminate race conditions, and can focus on developing that revolutionary game.
I knew a very, very bright person who could come up with some great and clean code. He definitely understood the problem and his solution was "optimal." Problem, before he even started coding he did an insane amount of research. Not just learning syntax, common patterns, etc.. but to the point of memorizing the entire standard library and reading several books on the problem domain before even beginning with some hash-it-out code. This wasn't for hard problems, just simple CRUD apps (for the most part.) Made it impossible to work with him as a team member.
I must say I'm really curious. What was his career trajectory? Has he been successful since?
My understanding of the Feynman Algorithm was that it was basically a joke by Gell-Mann. Gell-Mann was pointing out that no one else on earth (even himself, a Noble prize winner) could work the way Feynman did, the joke being that he only needed three steps: (1) Write down the problem. (2) Think real hard. (3) Write down the solution. It was about the absurd brilliance of Feynman, not intended as any sort of useful model to follow.
That does not mean one shouldn't plan, and know why his hacks work. Just that non-hackish solutions normaly only work in already solved problems.
"Try until it works" is a mark of an inexperienced craftsman - simply not knowing enough about the tools, the particular domain and the problem at hand forces one to try and try again until something works.. but that kind of "accidental" approach is inefficient compared to an intentional, measured approach.
It's very humbling to work alongside an older, experienced developer - the proportion of time they spend writing actual code is relatively low; most of the time is spent on working out the assumptions, the constraints, teasing out the larger picture from the details, and constructing a technical design... the actual code-writing is like a few quick yet measured strikes of a samurai sword - quiet, almost invisible, frighteningly effective.
Sounds like you need some more meta. If "trying until it works" is your algorithm, why not have a program execute it for you? ;)
Of course you could formalize those heuristics... trying until they worked ;)
Programming requires more precise understanding.
Where else would one getting precise understanding, anyway?