I agree with your review, and Eliezer’s afterword, in that this story misses the mark on effectively transmitting Economic knowledge; though I still have to see how the FAQ compares. Overall it makes for a light read and a nice intro to the topics in question to start building intuition and show possible topics to learn more about.
This is the second time I’ve come across Eliezer’s fiction writings thanks to a review on LessWrong (the other being Review: Planecrash), thanks for bringing the story up. I wish there was a more easily/visibly accessible list of his longer-form writing; it hadn’t occurred to me that he had more stuff other than The Sequences, HPMOR and IABIED if it hadn’t been for posts like these.
Mentally Outsourced Murphyjitsu.
I’ve recently been reading the CFAR handbook and after the Murphyjitsu chapter I realized that I use a similar technique that starts from a similar but I haven’t seen mentioned.
When thinking about a problem or a project, Murphyjitsu calls to think of a future that went wrong and asking oneself “what went wrong?” to come up with possible paths to tackle that you might be glossing over in your thought process due to different biases or cached answers. What I usually do is, instead, make up a fictional critic; it can be a smug smart-ass, a user for your app, or anything that ideally doesn’t see the world the way you do, so that their viewpoints and interest sometimes clash with yours.
Often, the most useful thing that this character says is some variation of “Why didn’t you just do this [thing]?”. Surprisingly, it doesn’t bump into the usual problems when someone external to a project asks that sort of question of beating on the same topics that have been thought through and already decided on, consuming valuable work time. This is, I guess, possibly due to the critic being privy to your own thoughts and knowing what’s useful to question or not.
I regularly apply this technique at certain intervals while working on a project, usually before deciding on what to work on or when thinking on what I could improve. I’ve personally found that it really helps me to notice possible issues before they arise, usually problems that originate even as far back as the planning phase, possibly due to not wanting to do the work that taking a certain path would entail, time or resource limitations at the moment of planning, or even things that I hadn’t thought of before (for example, use cases or wants from a certain kind of user that design didn’t take into account)
P.S. Taking opinions on possible names for this technique if it’s worthy of one; I hadn’t verbalized it before and didn’t know what to name it.