A hacker would probably come up with exactly the same algorithm, though probably written more quickly in another language, and with a few more compile/run/debug cycles.
The thing is: the mode of attack - breaking down the problem into simpler subproblems, solving one at a time, and in such a way that you're pretty sure that each step is correct - is used by both successfully. It reminds me of a study I read many years ago in Gerald Weinberg's Psychology of Computer Programming. The investigators studied the work patterns of many good programmers, and one of the variables they studied was number of runs per day (this was back in the day when one submitted ones program as a deck of punched cards to be compiled and (possibly) executed. They found that the good programmers tended to divide into two groups. The first (more akin to Dijkstra) mostly submitted a program which compiled cleanly, and executed, followed a significant time later by another. The second group submitted a program, got either compilation or runtime errors, quickly submitted a fixed version, perhaps iterating a few times, then went off for a while till they went through the quick cycle again. The point is: each group consisted of equally good (as far as could be measured) programmers. Both styles are usable, both styles are necessary to have in your arsenal: you need to be able to think through a problem, and prove your solution correct; and you need to be able to tackle it piecemeal and experimentally when it's too tough to tackle all at once.
See for example http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW... where Dijkstra goes, in painstaking detail, through the process of solving the "8 Queens" problem, building up the solution piece by piece.
A hacker would probably come up with exactly the same algorithm, though probably written more quickly in another language, and with a few more compile/run/debug cycles.
The thing is: the mode of attack - breaking down the problem into simpler subproblems, solving one at a time, and in such a way that you're pretty sure that each step is correct - is used by both successfully. It reminds me of a study I read many years ago in Gerald Weinberg's Psychology of Computer Programming. The investigators studied the work patterns of many good programmers, and one of the variables they studied was number of runs per day (this was back in the day when one submitted ones program as a deck of punched cards to be compiled and (possibly) executed. They found that the good programmers tended to divide into two groups. The first (more akin to Dijkstra) mostly submitted a program which compiled cleanly, and executed, followed a significant time later by another. The second group submitted a program, got either compilation or runtime errors, quickly submitted a fixed version, perhaps iterating a few times, then went off for a while till they went through the quick cycle again. The point is: each group consisted of equally good (as far as could be measured) programmers. Both styles are usable, both styles are necessary to have in your arsenal: you need to be able to think through a problem, and prove your solution correct; and you need to be able to tackle it piecemeal and experimentally when it's too tough to tackle all at once.