As students look for good fits with potential research advisors, they often wonder about this intangible quality called advising style. At first, it seemed like an unfair question, when a candidate would inquire about my style. However, I think I've since figured out what's distinctive about the way I collaborate with students, so here's a summary that may be helpful.
- Engineering, not theory: I'm interested in better ways to build computer systems, validated by constructing significant prototypes. If a project doesn't involve writing at least thousands of lines of code, it's probably not my style. Students who use the tag "theory" to describe their interests within programming languages or formal methods probably shouldn't apply to MIT's CS PhD program.
- Long-term orientation: I like to figure out how to do things the right way, even it takes decades to make the new ideas practical. Many people are thrown off by my presence in the "engineering, long-term orientation" quadrant of R&D styles, where engineering finesse really matters to me, even if it's fine if CTOs of all today's tech startups laugh at our ideas as impractical... for now. I try to recruit only students who are the best of the best at both software/hardware engineering and rigorous math proofs.
- Focus on training future research leaders: I try to recruit PhD students who I believe are likely to be fabulously successful themselves one day as faculty leading research teams and having the same kind of impact I aim for. That means I value independence, taste, and creativity in selecting problems and solutions, much more than willingness to play nicely within projects I design myself. The result is my "hands-off" advising style, where I'm very happy to see students work as independently as they're ready for.
- Systems above papers: I don't think of research as fundamentally about publishing papers, and indeed I can be downright lazy making sure each project gets published about promptly. Instead, I think of my job as fundamentally about finding things that bother me in computing practice and developing prototype systems that demonstrate better ways, with evaluations that show they really do make things better. I don't mind planning to have several students spend several years working together on a prototype (without publishing any intermediate papers), because we can't answer the questions we want to answer with less work. (It doesn't hurt to find ways to spin out papers on intermediate milestones, but I don't think of it as a requirement.)
- Ideas above specific code bases: At the same time, I try to do basic research, which means our outputs are ideas, not specific code bases. Sometimes we accidentally create a "prototype" that sees wide real-world adoption, but mostly I push for just the level of "good software-engineering practice" that is necessary to let us answer the scientific questions, not to create and maintain anything like a product anyone would pay for. (Since we are doing research in how large computer systems should be built, we still do need to think very hard about how to organize code bases and teams to keep everything manageable! This part is especially counterintuitive for many people.)
- Coolness above comfort: I'm quite happy to follow students into new research areas (especially with interesting, underexplored connections to what I already know), even if we see it will lead to a much longer delay before first results are ready, compared to pumping out papers in our comfort zones.
- Clean-slate above large ecosystems: Pick an element of how computer systems are organized today, and I'm likely to find it pretty gross. I prefer to redo things from scratch in whatever I feel like is "the right way" today. I try to see beyond advantages that come from having large existing code bases to drawn on when, for instance, choosing a particular programming language. Again, we are not trying to build a product but instead learn about how things should be done. I genuinely don't mind planning projects where literally every single line of code in software and digital hardware is written from scratch by us, to test out some new holistic design approach.