Wearing many hats as a CS PhD student

Feb 9, 2021 #researchthoughts  

Recently, some friends have asked me the question “as a PhD student, what does an average day for you look like?”. Leaving the typical PhD-lack-of-productivity jokes aside, I’ve found that this is something many of my peers have fairly low insight into. Prior to starting my own journey into research, I didn’t have a single family member or friend in academia.

I’ve seen Philip Guo summarize his view on the differences between pursuing a CS PhD and going into industry in a (now deleted) talk recording, and it stuck with me so much that I think I can still now paraphrase its concept. Working on any major innovative project incorporates three major areas: (1) design, (2) engineering and (3) marketing. In industry, you’re assigned to a team that focuses primarily on one of these areas. In a PhD, you’re forced to constantly shift your time and thinking between all three.

Like any generalizing thought, this won’t be entirely accurate. But it’s a useful enough way to think about the role of a PhD student, so let’s go one level deeper and discuss the ways in which PhD students wear many hats.

Design involves collecting information from the world, finding the overlap between observed opportunities and capabilities, and creating a compelling solution in that space. In practice, this involves reading research papers, attending talks, discussing ideas with your advisor/other researchers, and writing many, many pages of notes. I’ve noticed that this is the part of research that many early stage PhD students struggle the most with. I can think of several reasons why:

• Novel design is not a skill that most CS/Engineering undergraduate programs train. In most course projects or even summer research internships, a well-scoped, safe problem is presented to you, with clear constraints and requirements.
• Because this can be very difficult, many PhD advisors protect their students by handholding their students through this process and handing them well-developed research ideas. A common starter project in a PhD program involves an eager first year PhD student hopping onto an established senior PhD’s project. At this point, the project is likely quite mature, and the first year student gets the undergraduate intern experience.
• Working actively on design doesn’t produce measurable progress. While ultimately useful in the long run, your advisor might be displeased if you told them you spent several weeks “thinking really hard about a problem”. The compulsion to write code or run experiments wins out here.

I am by no means an expert at this, but maybe I’ll write more about the research design process in the future, since it seems to be in demand. I’ll just say this: if you’re an early stage PhD student and you don’t have a place where you regularly note your thoughts and ideas, start now.

Engineering is fairly straightforward and is quite similar to what most of your peers in industry are doing now. This usually involves building a proof-of-concept that is relevant to your research idea or writing code to execute convincing experiments on that proof-of-concept. Unlike industry, the overall goals are slightly different here; research code needs to work well enough to sell your research idea. It doesn’t matter much if your code fails on certain edge cases, or wouldn’t scale to a production-level environment. Unless releasing research code is a planned contribution of your work, tests and documentation are also often overlooked. Because of this, there is a bit of a stigma surrounding PhD graduates who ultimately decide to enter industry; they are thought of to write low quality code, especially when compared to software engineers who spent the same amount of time in industry.

Marketing is the step of convincing external stakeholders that your solution is relevant, novel and of high quality. Research involves tying supporting evidence to research claims; marketing is when you convince stakeholders that you’ve properly done so. In practice, this involves writing research papers, preparing and giving research talks and more informally, pitching your ideas to colleagues. Since claims are so tightly tied to a project’s pitch, I’d also be inclined to say that experiment design falls here too. This is an often overlooked part of the CS PhD, but like it or not, spending 5+ years in research will build your writing and speaking skills tremendously.

For a successful, end-to-end research project, a CS PhD student will likely invest several months on each areas. It’s also rare that work in each area is performed sequentially, especially when considering the likelihood of paper rejections. A paper can be rejected for inadequacies in any of the above areas, forcing you to loop back and reconsider its design, engineering or marketing.

Note: My MSc advisor Ivan Beschastnikh gave a talk for EuroSys2020 that touches on the research process and how it relates to rejection. See the first 15 slides of this talk.

Closing. So, let’s revisit. What does an average day look like for me? The cliche, cop-out answer is that there is no “average” day for me. It mostly depends on what state my projects are in. I personally find it easier and more refreshing to work on multiple projects at once, so sometimes I’ll be editing the paper for one project, while writing code and reading papers for another. Because of this, most of my days are fairly dynamic and open; I will personally spend two hour blocks shifting between any of the above tasks at a time. Of course, this doesn’t even include the typical coursework or TA requirements that many PhD programs also have, which also add a lot of context switching.

Parting thoughts and advice

(1) It’s important not to overlook any of the three major research areas by simply classifying them as “necessary evils”. I’ve personally either been involved with or closely observed research projects that have completely sunk due to failures in each of these areas:

• A well executed idea is made obsolete because another piece of unnoticed work has or is clearly able to solve the problem in a strictly better way. There is almost no path forward in this state.
• The code for a project is in such a bad state that additional experiments can’t be executed and desired features can’t be implemented. Costly engineering decisions were made early in the project and, instead of fixing them, the team is better off starting from scratch.
• A novel idea with solid implementation is ultimately presented in the wrong way, and the corresponding research community is unconvinced. For whatever reason, the project gets tunnel vision and attached to this pitch, and the work is perpetually rejected.

(2) If you are an early-stage PhD student I think there is value in asking yourself some of the following questions:

• What parts of the research process am I currently more/less comfortable with?
• What parts of the research process do I expect my advisor to help me the most with? Are they currently doing that?
• What parts of the research process is my advisor helping me too much with? Could I stand to learn and grow more if things were done differently?

(3) I’ve recently had a friend remark that “PhD graduates make great entrepreneurs”. There are a lot of factors at play here so I’m still not sure if we actually have a noticeable advantage over our peers in industry. But, like PhD students, entrepreneurs wear many hats, also often at once. After one spends several years working in this way, it’s easy to see why this would be an easy transition to make.

Thanks to Alejandro Cuevas for some helpful feedback on this post.