Some of this I’ve written about before:
Specializing in Problems We Don’t Understand largely talks about what-and-how-to-study, and the “formal study” parts of the apprenticeship should generally follow that. Aysajan’s recent post is an example of that: it’s taking chapter 2 of Jaynes’ Logic of Science and applying it in other contexts.
Comprehensive Information Gathering exercises. Aysajan’s first non-formal-study project is to read through lists of unsolved problems on wikipedia, as well as all of the course descriptions in a course catalogue from either MIT or Caltech.
Those definitely don’t cover all of it, though.
So far, other than those, we’ve mostly been kicking around smaller problems. For instance, the last couple days we were talking about general approaches for gearsy modelling in the context of a research problem Aysajan’s been working on (specifically, modelling a change in India’s farm subsidy policy). We also spent a few days on writing exercises—approximately everyone benefits from more practice in that department.
We’ve also done a few exercises to come up with Hard Problems to focus on. (“What sci-fi technologies or magic powers would you like to have?” was a particularly good one, and the lists of unsolved problems are also intended to generate ideas.) Once Aysajan has settled on ~10-20 Hard Problems to focus on (initially), those will drive the projects. You should see posts on whatever he’s working on fairly frequently.
There’s a lot of different kinds-of-value which mentorship can provide, but I’ll break it into two main classes:
Things which can-in-principle be provided by other channels, but can be accelerated by 1-on-1 mentorship.
Things for which 1-on-1 mentorship is basically the only channel.
The first class includes situations where mentorship is a direct substitute for a textbook, in the same way that a lecture is a direct substitute for a textbook. But it also includes situations where mentorship adds value, especially via feedback. A lecture or textbook only has space to warn against the most common failure-modes and explain “how to steer”, and learning to recognize failure-modes or steer “in the wild” takes practice. Similar principles apply to things which must be learned-by-doing: many mistakes will be made, many wrong turns, and without a guide, it may take a lot of time and effort to figure out the mistakes and which turns to take. A mentor can spot failure-modes as they come up, point them out (which potentially helps build recognition), point out the right direction when needed, and generally save a lot of time/effort which would otherwise be spent being stuck. A mentor still isn’t strictly necessary in these situations—one can still gain the relevant skills from a textbook or a project—but it may take longer that way.
For these use-cases, there’s a delicate balance. On the one hand, the mentee needs to explore and learn to recognize failure-cases and steer on their own, not become reliant on the mentor’s guidance. On the other hand, the mentor does need to make sure the mentee doesn’t spend too much time stuck. The socratic method is often useful here, as are the techniques of research conversation support role. Also, once a mistake has been made and then pointed out, or once the mentor has provided some steering, it’s usually worth explicitly explaining the more general pattern and how this instance fits it. (This also includes things like pointing out a different frame and then explaining how this frame works more generally—that’s a more meta kind of “steering”.)
The second class is mostly illegible knowledge/skills—things which a mentor wouldn’t explicitly notice or doesn’t know how to explain. For these, demonstration is the main channel. Feedback can be provided to some degree by demonstrating, then having the mentee try, or vice-versa. In general, it won’t be obvious exactly what the mentor is doing differently than the mentee, or how to explain what the mentor is doing differently, but the mentee will hopefully pick it up anyway, at least enough to mimic it.