Recently I reflected on the kinds of problems I’ve worked on during my PhD, and in doing so realized that I likely did not fully appreciate what research was until rather recently.
Research is about identifying and solving novel, important, and generalizable problems inherent in nature. Looking back on the problems I’ve solved for my PhD, I realize that I might have (at the time) confused the methods used to tackle the research with the research itself.
I think this conflation is easy for any student to make, because it is the natural conclusion of the path you take before you start your PhD. In undergrad, you struggle (and succeed!) to understand complex technical devices used to solve problems. For example, a CS major may learn proof mechanisms such as the pumping lemma, diagonalization, or proof by structural induction. It feels natural upon starting your PhD to assume that research will be challenging in a similar way. For me, this was exacerbated by the fact that I saw so many technical devices used in research that I hadn’t encountered in my undergrad: things like Coq, category theory, and abstract interpretation.
In light of seeing these things, it feels natural to assume that the road to doing good research is climbing the mountain of concepts until you get to the hardest one you can find, and to keep working on it. For example, I assumed that CS research entailed extending Coq, category theory, or abstract interpretation. This is partially true (in fact, these are areas of research), but taking this viewpoint leaves out a large amount of equally (or more) important vision of research that merely leverages those techniques to explore some other problem.
Throughout my PhD I was challenged by this misconception, and I think if I had identified it earlier on I could have done even more (and better) research. In particular, confusing the techniques used to accomplish research with problems proper leads to a very limited set of problems to solve. Worse: it leads to problems that have been well explored by many people.
Eventually I realized that the quality of research was not determined by the complexity of the mechanics, but instead the merit of the problem itself. Instead of judging problems by how much math (or code, or person-hours, etc..) would be required to accomplish them, I judge problems by how clearly they identify a disjoint area of study which may not have been obvious previously.
Taking this viewpoint has a large set of positive consequences:
You can stop worrying that you aren’t smart enough to solve problems. Research is about identifying useful problems, but useful problems don’t have to be challenging per se. Of course, figuring out how to distill a complex problem into simple pieces is often exactly the challenging part of research.
I can start with a question I care about and find interesting technical work by assessing the gap between the current technical solutions and my problem.
My research interests branch out beyond a subfield of computer science to expand to all of science as a whole. Instead of viewing myself as someone who works on problems X, Y, and Z, I can view myself as someone who works on problems, and is influenced by (but does not exclusively use) X, Y, and Z.
Taking this viewpoint of research has also helped contextualize the research I have done into a broader narrative of what I think of as the set of problems I care about.