[chisophugis]

I spent about a week going through Mahajan's OCW course "the art of approximation" (it's quite short and reads quite quickly). It changed how I view problem solving and engineering estimation forever.

Grab "entire book" (about 130 pages) at http://ocw.mit.edu/courses/electrical-engineering-and-comput...

"The Art of Insight in Science and Engineering" looks like a refined and expanded version of the OCW course. Like 6.055J, I'm sure it can be read casually and in small pieces. Do yourself the favor of checking out 6.055J or "The Art of Insight in Science and Engineering" (although see the caveat below).

Every chapter of 6.055J was mind-blowing for me. The "tree" technique. Using dimensionless constants. The random walk model of errors (i.e. why approximations end up being pretty good usually). Easy cases. Etc. A lot of it is just becoming aware of techniques we already use subconsciously or awkwardly; hence we learn to systematically and effectively use them.

One small caveat: Some of the content unfortunately doesn't extend super well into software/programming. Many of the useful properties that enable reasoning about physical systems (units, conservation laws, symmetry, equilibrium points/linearization, continuity, etc.) are not applicable to software in general since "anything is possible" in software. The software is basically in its own universe that has its own laws completely determined by the hardware/VM/language/API designers. It communicates with the "real universe" through very narrow and controlled channels. Some things from the book are applicable to software, but presented in a way that is strange or not terribly useful for software (e.g. "proportional reasoning" is just the familiar big-O reasoning).

[sanjoy]

Thank you for the comments. I agree with your caveat about the difficulty in applying the tools to software or programming. Although invariants are quite useful in programming too, and abstraction is an essential part of any large project. But I decided, perhaps wrongly, not to discuss the programming examples much. For example, an earlier draft had a discussion of abstraction and used the tree minilanguage that I wrote to make the tree diagrams, comparing the high-level abstractions it uses with the low-level lines of postscript or PDF code (near the bottom of the abstraction tower). But it ended up frightening lots of students, so I didn't include it in the published book.

-Sanjoy Mahajan