My last first graduate lecture of the year

Every few years, I have the opportunity to teach UBC’s graduate-level “Advanced Operating Systems” course. The course is a breadth requirement for grad students in the department, and so it has a diverse set of students, not just folks who plan to actually do systems research. I like to use the first lecture to position operating systems research much more broadly than just OS kernels, and to take advantage of one of the first lectures that the students get in grad school to share a few ideas about how to get the most out of the next few years.

In two weeks, I’ll be leaving my faculty role at UBC. As this is the last time that I’ll be teaching this course for the foreseeable future, I thought I’d put a sketch of this first lecture into a blog post. Here it goes:

Why are you here?

UBC’s CS department is among the top departments for computer science research in the world. Surely, if you were able to get past the admissions process here, you could easily have landed a high-paying job at Amazon, Google, or Facebook. So aside from demonstrating a fairly poor understanding of the concept of opportunity cost, why is it that you’ve decided not to take a job and to instead spend the next 2-5 years in graduate school?

This is not a rhetorical question!

Agency

I’d like to encourage all of you to think carefully about your answer to this question and to revisit that answer periodically over the course of your studies here. There are some very good, even sensible answers that you might offer, but offering those answers is going to demand that you think a little about how you are going to spend your time in grad school.

One answer is that you want to enter a career that requires an advanced degree in CS – likely either that of a professor or an industrial researcher. If this is the case, I would point out to you that the degree that you have signed up for is necessary, but in no means sufficient to get where you want to be. I would encourage you to learn, as quickly as you can, what it is going to take in terms of publications, software artifacts, connections, and even the institution that grants your degree in order to get there.

Another, distant but equally valid answer is that you aren’t ready to go work for someone else yet. Maybe you feel that specializing for a couple of years (in, machine learning, for instance) is going to open up some new opportunities. Maybe you are thinking about starting a company and want the time to learn and develop those ideas. Maybe, as was the case with me at the end of my undergrad degree, you just aren’t ready to commit to a full-time job yet. Hopefully, across all of these things, you are at the very least least here because you are insanely curious.

So here’s the first big point that I’d really like to impress on you at the start of graduate school, and it relates to the comment that I made above about opportunity cost. Given that you have the opportunity to go and get paid oodles of money to work on some probably-quite-interesting things, please be completely aware that you are choosing not to do that. You are choosing not to get hands-on experience building real production software. You are choosing not to learn how organizations that build that software work, and how you in turn should work effectively within them. Let’s be clear that even outside of the paycheque, there is all sorts of value and learning to be had down that other path.

Let’s agree that in deciding to pursue this graduate work, that you are choosing, in one form or another, to indulge yourself. In making this choice, you are exercising a degree of agency and self-determination that is going to take you to some very interesting places down the road – but please realize that you are doing it, because the next few years are going to demand that you keep doing it!

Operating systems as a new problem domain

So now let’s talk about why you should be interested in the history of operating systems. In particular, let’s understand why studying operating systems in this seminar for the next four months is going to be incredibly valuable to you even if you have absolutely no interest in them!

Operating systems represent a really remarkable class of computer software. Their job is fairly prescriptive, which is to say that they have focussed on solving pretty much the same broad problems for literally generations. But here’s the interesting bit: operating systems represent one of the very few examples of software systems for which the design, architecture, and evolution has been extensively studied, discussed, and frequently, even passionately, argued about since the very beginning of computing.

Here’s another strange thing about operating systems: while the goals of these systems have largely stayed the same for the fifty odd years that we’ve been building them, every single aspect of the environment in which those goals are to be achieved has changed. As an example, processing power was limited and expensive, then Moore’s law kicked in and it was plentiful and cheap, then Moore’s law stopped delivering and processing became limited (sort of) but stayed cheap (in parallel). The papers that we read in this course will survey the development of tools and approaches, sometimes even “principles,” to building good software in the face of an underlying physics that is changing on an almost yearly basis. The result of this continuous change, which largely has to do with the differences in relative technical capabilities of computing, memory, and communication, is that the discipline that emerges – computer systems – must constantly be aware of these properties and must train to be able to justify the tradeoffs that their systems make in the face of them. One of the most surprising aspects of systems as a field is that these approaches and principles have endured despite such continuous and tectonic changes in the underlying hardware.

We are going to begin by reading papers from the 1960s. At that point in time, we will watch early researchers “discover” many operating system primitives that we take for granted today. Those researchers will describe those primitives using frustratingly unfamiliar terms. What’s worse, where they do use familiar terms, those terms will not carry the baggage that half a century of use has provided for them, and you will need to look at them through a lens that is also free of such encumbrances.

In short, even if you think you know all about operating systems, you are all about to be asked to dive into a completely unfamiliar body of work, and to quickly come to a place where you understand it well enough to discuss it competently, to criticize it, and to synthesize new ideas from it. These are the things, far more than the specific mechanics of operating system design, that I hope you will take from this course. Because these are the abilities that you will benefit from again and again throughout the rest of your career: to effectively charge into a new area – whether it’s a new job, a new codebase, or a new language – and become conversant. This is one of the core benefits that you will get from grad school, and it will come the most from the areas that are not the ones where your interests already lie.

Influence

So let’s tie these ideas together. First, you are here, whether you realized it this morning or not, out of an act of personal agency. You’ve taken a decision not to dive into the (paid part of) the knowledge economy (quite yet). Second, as a particular consequence of that decision, this course is going to offer you an opportunity to get practice in the abstract skills associated with learning and becoming productive within an unfamiliar area of knowledge.

Let’s make one last observation about what you are really going to learn over the next few years. I’d like to propose that wherever your career leads you after this degree, that the enduring skill that you will learn here will not actually be in the nuts and bolts of a specific subdiscipline of computer science. I would argue that the most valuable opportunity that you have in choosing to pursue a graduate degree is that of learning to influence. And just to be clear, by influence I don’t mean in the subversive, machiavellian sense of that term, but rather, simply, as the ability to apply your ideas to make a difference in the world.

Everything you do over the next few years is going to be about showing that your ideas have merit, and are, in fact, compelling. This will happen in the small during our seminar discussions in which I will expect you to take a position and argue for it. It will happen at a larger scale with your own research: First you will decide why you want to build something and then you will decide how to build that thing. From that point forward, everything you do is an exercise in influence. The artifact that you produce is an existence proof, but is hardly sufficient. You will design and run experiments that demonstrate that it does what you built it to do. You will learn to argue for its value in published code, in writing, and in speech. If you work hard you will realize that the venues for that influence is just as frequently personal and direct (hallway conversations at conferences, github comments, and email) as it is public (conference presentations and published papers).

Irrespective of whether you go on to take a software development job after this degree, go on to a faculty position, or switch careers altogether, I maintain that learning this act of influence is just as valuable, if not more, than anything else you will learn in these classes. Moreover, and this bit is important, the ability to identify and advance a specific position, that you will learn in the context of this degree is effectively risk free in the context of graduate school: your salary doesn’t depend on it, nor, really, does your reputation. So please do yourself the service of engaging and participating in class, lab, and conference discussions – even if you are as terrified, as many of you probably are – because it’s the only way you will improve.

Influence takes work

At this point, some of you are making puzzled faces: “Wait a sec,” you are saying, “I thought this degree was about learning to identify research problems, learning to carry out sound research, and learning to apply the scientific method!” Your graduate degree is absolutely about all of those things. And more: once you have validated your hypotheses, and produced solid measured results you also need to clearly articulate those results in text and oral presentation.

The bottom line though, and the thing that I really hope to be able to impress upon you is that even this is not enough. Even if you learn everything about your subfield, identify a great problem, do great work and write a solid thesis, the likelihood that your thesis will be read by an arbitrary passerby is really pretty darned small. This “front half” of the research process is important in that it is required to give authority to your position. Influence though, is not just that authority but also the application of that authority to have impact on others.

From this perspective, the discussions and arguments we have in this class are more important than that unread thesis. They are more important because as long as you make the decision to participate in these discussions, you will have the opportunity to directly impress your position on someone else, and you will have to listen to theirs. As a result, you will both learn. This hands on, tactical effort to advance your beliefs is the “back half” of the research process. Influence requires both halves: the earned authority on a topic, and effort to share it with others.

And so this is what I hope you will take from both this seminar, and the next few years of your studies: you are here to explore, to learn, and to learn to think. But at the end of this process, you are here to learn how to fortify your own ideas sufficiently that you can use them to shape the people and organizations that you interact with. That influence will often be on issues that are rather smaller than your graduate dissertation or even the project for this course, but your successes in applying it will be no less meaningful.

Now, let’s talk about operating systems…

Thanks to Mihir Nanavati, Brendan Cully, Tony Mason, and Bill Aiello for feedback on this.