[TeMPOraL]

It's a great book (I'm just about to finish it). But let's not forget that the goal is to internalize problem-solving heuristics so that you use them intuitively.

In fact, the book itself has two audiences - the problem solver, and the teacher of future problem solvers (with the suggestion that if you're the former, you can also be the latter by talking to yourself). So the book gives you both a bunch of stuff to internalize, and a discussion on how to teach that stuff to other people.

--

Tangentially, reading this is making me do some serious soul searching about the way I approach programming. For instance, Polya emphasizes reviewing your work as an important step in solving a mathematical problem - not (just) to re-check correctness, but to spend some time thinking about the structure of your solution, and learn something from it. This is something I just realized I rarely do in programming - I don't review my code to learn more from the very solution I just implemented. I usually just commit and continue to the next thing. This is a thing I'm going to work on changing.

[ellius]

The hard part of this is that most companies aren't willing to support it (monetarily). You're expected to spend most of your time coding or, at best, thinking about the next problem. Thoughtul reflection rarely gets the support it ought to.

That said, I think it's worth investing your own time in doing it. I feel a lot more at ease when I take time to think about my work, and I think it pays off in my own career in the long run, even if it costs me some of my own time.

[icc97]

I do typically review my code just before I commit it as I write the commit message, but it's not much of a high-level overview.