Find Problems for Processes Rather Than Processes for Problems

I think that, naively, we tend to see a thing that we want and then formulate a plan to go and get it. Like, "I want to make $50M and retire on an island", and then we start formulating plans, doing the calculus, and experimenting. And, obviously, there's a lot of sophistication that happens in between seeing the thing that we want and figuring out how to get it. But, often we can get better gains by finding a really good process and then finding problems that it applies well to. This kind of inverts the advice, "When all you have is a hammer, everything looks like nail." We're supposed to take away the idea that we need tools which are better suited to the job. But, maybe our takeaway should be that we actually need to go and find more nails.

These are some examples that make really good use of the principle:

• The vast majority of the stuff that we build has a cuboid shape, because cubes are easy to reason about. Imagine how much harder things would be if we didn't.
• We know how to parse context-free grammars, so that's what we do. We avoid contextual grammars, because we don't have the tools to deal with them.
• We stick corn in everything, because we have a lot of corn.

I think maybe there's a tendency to sort of absorb these kinds of approaches into our culture so that we're not even thinking about them consciously most of the time. We usually think of these things as limitations in a "glass half-empty" sort of way rather than thinking of them as special cases of problems that we can solve very efficiently and effectively. The latter perspective encourages us not to wait until we're blocked, but rather to reach for this kind of thinking as an optimization early in the process.

Of course, if we take this approach, we won't get want we wanted strictly speaking unless what we wanted was very general ("some kind of really efficient process"). But, often what we want actually is very general. For example, "making money" is very general; there are many many ways to make money and it does tend to correlate well with the application of efficient processes.

One cool thing that I've been thinking about recently as a result of this kind of inversion: Code generation is really efficient but also really dumb. How do we design systems that can work with really dumb components, which can be easily generated, and compose them together to build real sophistication rapidly?