What I tell people asking whether they should do a PhD

Last week, two students asked me whether they should do a PhD in computer science, both in visual computing. One in computer vision with an accent on robotics, one in computer graphics with an emphasis on rendering and animation. Ultimately, your choice needs to be aligned with your goals, and a PhD is not for everyone for the simple reason that we don’t all have the same goals. Nobody else can make this decision for you. However, I think the people who asked me had some wrong preconceptions about what a PhD prepares you for. They’re probably not the only ones, so hopefully this post will be useful to others.

Before getting into it, three things to know about where this perspective comes from:

1. I started my PhD in June 2021, and my decision was based on my Master’s thesis at ETH, performed with my advisor at the time. Why did I do a PhD? I’d like to pretend there was a deep, cold or calculated answer to this question. But this is not true. I did it because I liked the way I worked and what I worked on during my Master’s thesis. My collaborator told me that it was pretty much the PhD life, and I saw little reason not to do what I liked, especially given the opportunity to do it in a University like ETH. I had no clue about the repercussions on my career. Furthermore, I had the benefit of not feeling overwhelmed by AI development at that time, which I assume makes having to choose what to do with your life at 24 way more anxiety-inducing now than it used to be.
2. I only did a PhD and have not continued through academia. This post is about my own impression, but as you can tell, it does not come from a professor with 30+ years of experience and a lot of stepback. If you want a much deeper understanding of academia, you probably need to talk to someone who has been doing it for a longer period of time.
3. This post presents my own opinion, but I’m not sure it’s necessarily the consensus. It’s here to help students to make a more informed choice, but again: talk to more people. Others might disagree, and it’s a good thing to compare several perspectives.

What you need to understand is that a PhD is not a degree in advanced engineering. The goal is to train you as a scientist. Which you can combine with engineering later on in the industry, when you’re developing new technologies or cutting-edge products.

There is a misconception that a PhD in computer science aims at making you great at developing technologies. While science and technology are intertwined and rely on each other to make progress, they are not interchangeable. The difference is subtle, but exists. So what is science, and how does it differ from technology? Science is the art of finding good explanations of phenomena, while technology is the art of building things that work.

There have been a few papers where the technical change (i.e. the actual amount of code necessary to implement the proposed method) was extremely small, while the contribution itself was substantial. Yes, you can still publish at the best conference with the lowest amount of code possible. This is perfectly exemplified by this SIGGRAPH 2024 paper from Chen et al., where the authors write “this leads to an extremely simple and elegant solution, requiring only one line of code change in the existing projected Newton framework without any additional parameter.” The line change is:

Hi_proj = U *max (Λ,0) *U' --> Hi_proj = U *abs (Λ) *U'

The funny part is that the simplicity of the implementation is used as a strong argument in favor of the method, and is even emphasized in the abstract. More generally, good papers tend to be as simple as possible, but not so simple that it alters the quality of the explanation they provide. The contribution of the paper does not lie in its complexity, but in the insights and benefits that it claims over prior methods. Limitations are also very powerful, not only because they are part of the understanding of a method, but also due to their ability to foster further development in a given field.

On the other hand, technology can and often does require handling extremely complex (as in, with a lot of moving parts) and scalable systems. Systems that can potentially accommodate millions of users at the same time. Models that require gigantic clusters for training. Codebases that are being hammered by dozens of engineers simultaneously. This is very different from a solo researcher figuring out the next experiment, barely holding a few Python scripts together with duct tape. Technically, one does not even need to understand why a technology works, which is why technology can die over time (as in, there are things that some humans used to know how to do, but they did not transmit their know-how). Technology can emerge from refining a craft over decades or generations, with a trial-and-error procedure, and does not require communication (patents are made to protect innovation, but technology can be developed and protected through trade secrets).

Science, on the contrary, does require communication to exist, generally through peer review and publications. The skillset you develop along the way is entirely different and varied, and communication is entirely part of it. I don’t mean “communication” as in “communicating with your colleagues on a codebase”, but as in coherently presenting your ideas to the community, both on paper and orally. You need to present the problem, explain why it’s relevant, describe the field, propose a method that has different sets of attributes, and carefully explain why it works and to what extent. By working a job as an engineer, you’re developing other skills. And there is a reason why it is said PhDs’ programming abilities are not that strong: this is literally NOT the core part of the job. Of course, your technical abilities will dictate how fast and how well you will end up creating solutions, but these remain relatively isolated codebases that will never really be used by others in serious scenarios without re-engineering. Something that might surprise you, but you get no credit for the quality of the code itself when you publish. It’s not a requirement to submit code at SIGGRAPH or Eurographics, and it’s only appreciated for reproducibility so that further papers can cherry-pick the best comparisons against your worst results. Naturally, some academics have outstanding programming skills and have created robust libraries used by millions, but this is either their deliberate choice, or because they work within a company that benefits from a well-maintained research codebase. When I worked on my first PhD paper, I deliberately delivered the code with the submission and wanted to learn how to use the Model-View-Controller pattern. This was for my own sake of learning some bits of software engineering, but all I got was a compliment about the codebase from a student whom I supervised and who wanted to work on this topic. Which is nice, but in my experience, scientists barely appreciate the engineering efforts.

The distinction between technology and science is often unclear because both rely on each other. Science gives the intuition for the next technological step, and technology empowers scientists to explore new avenues. On top of this, a very good way to be successful as a computer scientist is to develop something new and to claim that it’s better than what existed before at whatever problem you’re solving. It’s also way easier to claim that something does work: you have to show examples where it works and run a few metrics that strengthen your point. But still, it’s way easier than proving that something is impossible. Indeed, it’s not enough to show a few examples where something does not work. We can all do things that don’t work. Negative results need to be very well argued for, as in “proving that this thing will always fail”. Way harder, and not interesting for many people.

While computer scientists are also developing tech because it gives new things to explore and explain, the technical part is often limited, and I would even argue that the simpler it is, the better. Taking an architecture that already exists and making it more complex without explaining the role of each component, increasing the number of parameters and the size of the dataset, and throwing billions into training a new fancy chatbot may not account for a very strong scientific contribution. Why? Because we already know these strategies work. You’re not providing a lot of additional knowledge by saying that with a bigger model, you get better results. We kind of know it already.

Understanding this distinction should help you answer the fundamental question: what do you want to do with your life? If you want to build scalable systems and are not interested in scientific progress, then a PhD is likely not required. Don’t go do a PhD to work on a game engine, for instance. Game engines are fantastic pieces of engineering, but if what you like is to create complex shaders, provide high-quality libraries for many users, or write optimized code for games to run better, a PhD is not going to help you much a priori. It won’t hurt, but it might be a detour. And if you realize that you need to be a scientist in the job later on, then you can start a PhD with a stronger direction and technical abilities that will help you. If you want to develop technology informed by science, meaning you read papers, understand methods, and incorporate state-of-the-art into systems, you need to be able to read scientific work fluently. A PhD overcorrects for this a bit. Some people are not trained scientists, yet can digest papers’ insights and find a direction in which they want to develop a technology. A strong Master’s gives you the reading skill without the four extra years. If you are an entrepreneur, then nobody cares about your degree, but you need the right skills. Still, to be a research scientist in a company, a PhD will help you get hired by a lot. Finally, if you want to participate in extending human knowledge, you already knew the answer before reading all of this: a PhD it is!

What motivated this post, though, wasn’t just to underline the difference between science and technology. The question that came back was “is it not too risky doing a PhD?”. When I asked for more details about this fear, it sounded like people had two misconceptions. The first one was that you may not be able to produce the next best SOTA model, and hence your work won’t be useful. Spoiler: you won’t be SOTA. Your goal in academia is to create knowledge, not develop the technology that will rely on this knowledge. You’re in a university, not in a startup burning VC money into an attempt at creating AGI. This is the role of companies to leverage science to create technology. (Reality is more nuanced than this, of course)

The second one was that if you work on a topic that is not going to be exactly the next trendy thing, then the skills that you may have developed will be entirely deprecated. Yes, what you study during your PhD can matter to some extent. It’s far easier to find an industry job working on diffusion models than on theoretical differential geometry. Taking this into account will make your life easier than if you bury your head in the sand. But more importantly, it is a misconception that you will remain confined to the very narrow scope of your PhD expertise for the rest of your life. The most important takeaway from my PhD is the confidence that, with enough effort and patience, I can become an expert at virtually anything. I did not believe that in 2020, or at least did not have the data to back up such sentiment. During my PhD, I worked on four papers, and they were not very related to each other. I had to go through the pain of familiarizing myself with a new field four times. I got better at it, and I got the confidence that I could do it over and over again. Many researchers do not work on a single narrow topic; they explore. Which means that even though what you worked on during your PhD does not become the mainstream direction in the field, you still understand the field’s ins and outs, you still know how to adapt to it, and you can still apply the meta-skills that will make you ready way faster. A PhD is not a coin toss for your career. It is a choice, it has a cost, but it is a long-term investment that, given it is aligned with your life goals, will pay off.

I believe any scientist should read The Beginning of Infinity, by David Deutsch. This book deeply altered my perception of science and even life in general. The framing in this post owes a lot to his idea that science is fundamentally about finding good explanations, so in good academic spirit, I want to end this post by acknowledging its influence.