Common advice #3: Asking why one more time

Written quickly as part of the Inkhaven Residency.At a high level, research feedback I give to more junior research collaborators tends to fall into one of three categories:Doing quick sanity checksSaying precisely what you want to sayAsking why one more timeIn each case, I think the advice can be taken to an extreme I no longer endorse. Accordingly, I’ve tried to spell out the degree to which you should implement the advice, as well as what “taking it too far” might look like. Previously, I covered doing quick sanity checks and saying what you want to say precisely. I’ll conclude these posts by talking about probably the hardest to communicate category of common advice: asking why one more time.Asking why one more time In my opinion, the most important skill in empirical research is figuring out how to make your beliefs pay rent: you have many possible hypotheses about a phenomenon; to test them, you need to connect these hypotheses with empirical observations. While it’s all well and good to perform all the basic correlations and sanity checks that you want, it’s rarely the case that the problem at hand can be straightforwardly solved by looking at a few scatter plots. The second important skill in empirical research is close to the converse of the above: instead of looking at your hypotheses and trying to fit them to the data, you look at places where the data seems inconsistent with any of your hypotheses (i.e. surprising or interesting) and generate new hypotheses to explain the data. I think these two skills tend to form a research loop: while you’re confused, first generate more hypotheses about the data, and test the hypotheses against either current or future data (or vice versa). That is, testing hypotheses against old or new data will surface anomalies, which prompt new hypotheses, which in turn need testing, which prompt new hypotheses, and so forth. What counts as sufficient understanding for this loop? In my experience, you can often quantify the number of iterations of this loop you've completed by the depth of the natural why questions from a possible interlocutor that you can answer.[1] At the first level, we might ask questions such as, why does your hypothesis imply this empirical result? Why does the surprising result you’re trying to explain occur? At the next level, we might ask about the parts your hypotheses are made of: if your hypothesis is that the length of chains of thought predicts monitorability, why would this happen? Or, we might ask about why the surprising result didn’t generalize to other domains: if GPT-4o’s sycophancy explains many people’s attachment to it, why don’t other seemingly sycophantic models lead to the same level of attachment? Almost all of the researchers I’ve worked with have been incredibly bright (and from great research backgrounds) and have consistently thought about and can cogently answer the first level of whys. So I basically never need to give advice (though, if you’re not asking why your key result is what it is, maybe you should start!) However, a lot of the second level of whys that I ask (or that I ask them to generate) tend to highlight gaps in understanding and lead to fruitful discussion. For the sort of researcher I interact with, I think it’s good advice to take whatever answers to natural why questions you generate by default and then repeat the process of generating why questions exactly one more time for each of the explanations. Taking this too far. There’s a reason I say “ask why one more time” and not “continue asking why”. In general, as with many similar conversation trees, the space of natural why questions expands exponentially. At some point, you need to decide that you’ve done enough investigation, and research that never gets consumed by other people likely has minimal impact on the world.There are a few specific failure modes I’ve seen:First, and most obviously: never producing output. If you keep asking why without stopping, you will never finish anything. (This is a famously common problem around these parts.) Every explanation has sub-explanations, and at some depth you’re doing philosophy of science or metamathematics rather than object-level research. Again, there's a reason the heuristic is “one more than your default". Second, there’s a social cost. In collaborative settings, asking too many whys about someone’s work can feel quite adversarial, especially if it's a new collaborator. If a collaborator has a plausible answer to the first-level why and a reasonable sketch for the second, pushing hard on the third can start to feel like you don’t trust their judgment rather than that you’re trying to improve the work. Being explicit about your intent (“I think this is strong, I’m pressure-testing it because I want us to be confident” or "I think you're correct, but I want to check that I understand it myself") can help, but it's still a real dynamic that needs to be managed. Third, investigating the wrong whys. Not all branches of the why-tree are equally valuable. When you generate second-level why questions, some of them will point at load-bearing assumptions; others will point at irrelevant details. Some will be fruitful and easy to investigate, and others will be too hard or too costly to answer. Developing taste for which branches matter is a much harder skill, and one I don’t have great advice for (at least not one I can write up in a short post like this one) but as with all prioritization questions, one heuristic is to focus on the whys whose answers, if different from what you expect, would change your main conclusion.The optimal depth of whys you try to answer depends on how seriously you care about a result, but for research (in my experience) tends to vary between two (for blog posts or ideas that you don’t intend to seriously build on in the future) to three (for the core ideas of research papers that you do hope to build on in the future). ^I used to refer to this concept as simply “being skeptical”, but that fails to communicate the actual skill being executed here. I got this new framing from Thomas Kwa at METR (though any confusing parts are no doubt my own). Discuss