People of Systems & Architecture: Margo I. Seltzer (Part 1)

With most systems and architecture conferences taking the online route, we figured it’s a great time to get to know a few people in the systems/architecture research community. People of Systems & Architecture is a series of interviews conducted this year, and continues in the same vein as the People of PL, People of POPL, and the People of Language Design and Implementation interviews done by John Wickerson, Jean Yang, Brandon Lucia, and Minjia Zhang.

In this edition, Akshitha Sriraman meets Margo Seltzer, who is the Canada 150 Research Chair in Computer Systems and the Cheriton Family chair in Computer Science at the University of British Columbia. Her research interests are in systems, construed quite broadly: systems for capturing and accessing data provenance, file systems, databases, transaction processing systems, storage and analysis of graph-structured data, new architectures for parallelizing execution, and systems that apply technology to problems in healthcare.

She is the author of several widely-used software packages including database and transaction libraries and the 4.4BSD log-structured file system. Dr. Seltzer was a co-founder and CTO of Sleepycat Software, the makers of Berkeley DB, recipient of the 2020 ACM SIGMOD Systems Award. She serves on Advisory Council for the Canadian COVID alert app and the Computer Science and Telecommunications Board (CSTB) of the (US) National Academies. She is a past President of the USENIX Assocation and served as the USENIX representative to the Computing Research Association Board of Directors and on the Computing Community Consortium. She is a member of the National Academy of Engineering, a Sloan Foundation Fellow in Computer Science, an ACM Fellow, a Bunting Fellow, and was the recipient of the 1996 Radcliffe Junior Faculty Fellowship. She is recognized as an outstanding teacher and mentor, having received the Phi Beta Kappa teaching award in 1996, the Abrahmson Teaching Award in 1999, the Capers and Marion McDonald Award for Excellence in Mentoring and Advising in 2010, and the CRA-E Undergraduate Research Mentoring Award in 2017.

Professor Seltzer received an A.B. degree in Applied Mathematics from Harvard/Radcliffe College and a Ph.D. in Computer Science from the University of California, Berkeley.

A: Tell me a little bit about your career journey.

M: It’s a circuitous journey that had no pre-planning. One of the things that I always tell my graduating students, particularly undergrads, is don’t try to plan out the rest of your life; figure out what you’re doing next. In large part, that’s because I never could have predicted where I ended up. 

I grew up in the middle of nowhere in upstate New York in a teeny tiny school. It was a teeny tiny town where we had more cows than people. But, I was from an academically focused family; there was never a question of whether college was in my future. I was very much a math and science person. I remember that when I was in middle school, I fantasized going to Harvard. I have two brothers, both of whom are quite a bit older than I am. One of them had applied to Princeton and been rejected. This was always referred to as a “character building experience” in my household. So, I applied to Harvard, and I knew that I was going to get rejected, and that was going to be my character building experience. Except, Harvard had the poor sense to admit me. So, I went to Harvard. Now you have to understand that when I said this to people in my town, they were like “Oh, where’s that?”. I remember that my boss at the restaurant I worked was pretty excited; he would tell all his customers about it, but, most people were just like “Oh, that’s nice” [shrugs]. “Where’s that? Is that as good as the local school up the lane?”. 

So, I prepared myself for coming from a place where I was big fish in a little pond to going to a place where I was no one. I set myself up for that, which was fine. For me, college was a journey of figuring out things that I’m actually pretty good at. One of those was running things. Another, which I learned through both good and bad experiences, was leading people. I had a fabulous time in college and worked super hard, because I was basically paying my way through college as well. By the time I graduated, I was like, “I’m done with school. Maybe someday I’ll go back, but for now, I’m done.” So, I went and got a job and I did three startups in a period of five years. One of the smart (i.e., I made a lucky decision) things I did right around the time I graduated was taking the GMAT, LSAT, and the GRE tests. That was to keep all my bases covered. My thought process was that I was probably going to test better then than I ever would in the future. Also, the test results expire in five years, which meant that at some point I’d have to decide what I wanted to do. 

I was at startup number three and I got dumped by a boyfriend, like really hard. I was really upset and we tried to do the “let’s be friends”. After a few weeks, we decided we’d talk on the phone and he said, “what are you up to?”. I said, “Oh, I was thinking, maybe I’ll take a graduate course. If I like that, maybe I’ll apply to graduate school”. And he laughed and said, “Oh, well, that’s what you said when I first met you”. Now, he’d only met me six months ago, but I was livid. So I took a graduate class and then I applied to graduate school. I *do not* recommend this as a technique for going to graduate school, but it sort of worked out for me.

I was working for a company that was somewhat insane in a variety of ways. I had it in my head that if I went to grad school, they couldn’t be mad at me. Whereas if I left and went to another company, they could be mad at me. Again, not really a good decision making process. But, in fact, they were so mad that they sent letters to Stonebraker, Patterson, Katz, and Ousterhout explaining to them that I had been working on a proprietary project and under no circumstance was I allowed to talk about it. Now I assumed that they did this because they figured that that would torpedo my graduate career. Instead, it meant that I showed up in grad school with this mystique like, “Oh, who is this person for whom they felt the need to do this?”.

Grad school was great [thinks]. Um, no, grad school was not that great. I like to tell my students who start their PhD that there will be times in grad school when it’s really, really hard. I tell them “Just don’t hide if you have a problem. I’m here for you. We’ll get you through this”. Nobody told me that.

So, there were times in grad school when I wanted to quit.

In fact, at one point, my partner, who is now my husband, was looking at a possible job in a different state. And I was like, “Oh, please take the job” since then I’d have an excuse to drop out of grad school, because without the excuse, I couldn’t drop out [rolls eyes]. Like you just can’t do that.

By the time I finished, I figured that it made sense to go after the one job that I couldn’t have gotten if I hadn’t finished. And that was being a professor. Again, not the best decision making strategy [laughs]. But I went on the market. I was ridiculously successful and long story short, I ended up at Harvard. It was the best job in the world for me because, it turns out I don’t do really well with a boss. Academia is one of very few jobs in life where you don’t really have a boss. So, it actually turned out to be a great fit. It brought together the various aspects of me that I was really good at. I’m a people person, I’m an extrovert. But, I’m also a geek. I really enjoy programming and I like technology. Being a professor lets me do those two things. So, that is the journey full of really, really bad decisions. It still got me to an okay place.

A: Thanks! Moving on to my next question, what are some of your current research directions?

M: The fundamental problem I have can be described either as really broad interests or really short attention span. I do too many things. I continue to work in storage because that’s been my bread and butter since day one. I have an incredibly wonderful collaboration with Cynthia Rudin at Duke where we do interpretable machine learning. She does the math and I make stuff run quickly. We get awesome students to help us, and that’s been fabulous. I’ve got a bunch of stuff in graph processing and then my newest crazy endeavor has been program synthesis. Then, there’s my work in data provenance. I spent the first ten years I worked on data provenance worrying about how to get provenance and then realized that nobody cares about data provenance. What they care about is making their lives easier. So, now we use provenance; it’s a rich source of information upon which we can build tools that actually improve people’s lives. And then there are my three last Harvard students, one of whom is working on interactive program synthesis, another is working on interesting systems and security applications of whole system provenance, and the third is working on machine learning for program repair.

A: How do you come up with your research ideas? 

M: That’s a great question! I subscribe to many strategies, so I don’t have a good answer. One of my favorite answers was from Brian Bershad who said that he subscribed to the frying pan school of problem solving: after you hit yourself over the head with a frying pan enough times, you should stop and say, “Wow, that really hurts. I wonder if I could fix it”. Data provenance was one of those things, where documenting scientific processes is really hard when people don’t do it and it’s terrible. So maybe we could fix that. Similarly, with the program synthesis project, nobody likes writing assembly language, yet there are still places where people have to write low-level code. It turns out that, especially in the embedded, particularly embedded military platforms, they run software that is decades old. The reason is that it’s just too hard to upgrade the software. New hardware comes out, and it’s now too painful to upgrade software. So, how can we expedite that process and allow software to grow with hardware? 

I’ve never seen a research problem I didn’t like.

I talk to people and they’ll mention things that are interesting. Collaboration is really fun. I’ve got a couple of visualization projects going on, because systems people are often really good at producing interesting data and not very good at helping people use it. I am not somebody who knows how to solve visualization problems, but I can often identify things like, “Ooh, this is really interesting data! I wonder if there’s a way we could make it accessible to people”. I’m really excited about being able to visualize the data that we use to make intrusion detection systems, because in many cases, you get an alarm that says, “Oh, we think there’s intrusion”. And it’s like, “why?!” um well because some piece of software says so. I think it would be really great to give people the mechanism to dig down into it and get a sense of what’s going on. So, that’s been a whole fun area. 

My secret desire is that I want to spend the rest of my career trying to publish in as many different areas of computer science as possible. I’ve got my first PL paper under submission at the moment, but I’ve never published a theory paper. My ML papers have a lot of math in them though. I haven’t published in scientific computing either. So yeah, that’s my new fantasy.

A: Your research spans across a wide variety of areas. You’re an expert in a whole host of different fields.

M [interjects]: Or an expert in none [smiles kindly].

A: How do you go about working in all these different fields and maintaining the level of expertise that you do across all of these different projects?

M: It’s all smoke and mirrors?!

One of the things I love about being a professor is that a part of my job is to learn new stuff.

I learn a ton of stuff from my students and I think at some point they don’t realize that they know more about things than I do. I have to repeatedly tell them that, and they don’t believe me. I remember one episode this past year where it was a project in the storage area, and I was getting frustrated because there was something that I fundamentally didn’t understand. I knew the student did. It had never occurred to the student that I didn’t understand something that they did! I was like, “no, no, no, you really do”. I really want them to know that. That’s the great part about working with really smart students: they teach you stuff.

I learn a ton from my collaborators. In some ways, the places where I’ve had the most impact on my ML collaborations is where I don’t understand something and I keep asking until I get it. This makes the collaborator understand the different perspectives better too.

I think everybody has a superpower and part of your goal in life is to figure out what your own superpower is.

I am not the best systems builder. I’m not the best ML person by a long shot, but I am really good at synthesizing information from different places, putting it together, and seeing connections that maybe aren’t obvious to other people. A lot of research problems I’ve identified arise from asking dumb questions and then being able to see things in other areas that fit together. Initially, it never occurred to me that this was a skill, but it turns out that it is.

There’s an ability to be comfortable with figuring out the right layer at which you need to understand something. For a lot of us who are inherently control freaks, it’s super hard to say, “Oh, I understand it at this higher level and I actually don’t understand low-level details”. I think that’s a really uncomfortable position for a lot of people, but if you’re going to work across areas, there are going to be some areas where you’re going to have to draw a line and say, “okay, I can stop here”. I don’t know if this is a skill or a failure of a skill. Often with graduate students, one of the challenges, particularly when I’m encouraging them to do these bold, stupid, audacious (pick your right word) projects is helping them figure out that they don’t need to go all the way down to the bottom on every topic. You need to understand that this is the technology we’re going to use. So, you don’t need to understand how to develop it from scratch. But, I think learning where to draw those lines and say, “okay, for this project, I can be comfortable knowing things at this level, without going all the way down to the bottom” is important. I think I’m more comfortable than many people relegating some of that to a magical black box. But then, I sometimes get myself in trouble that way [laughs].

The biggest challenge for me is I don’t get big blocks of uninterrupted time. I feel that that would be a luxury and I can’t figure out how to make it work in my schedule because the students have a fixed amount of time to get their degree. My job is to help them be as successful as they can during that period of time. So, that’s where my energy has to go. I need to make sure that the students are doing their best work and that I am staying just enough above water that I can make sure that they’re swimming quite comfortably. I would love to have more time to just code for fun as I enjoy coding. But, I don’t have enough time to do that. 

A: What is your most favorite research paper?

M: I have a couple that I really like a lot from a pure technology point of view. I still love the VMware ballooning paper by Carl Waldspurger. We often read that one in my class and I think it’s just such a cute, clever idea. I also love the Martin Rinard failure-oblivious computing paper because it’s the first time and maybe the only time I’ve been at a conference and I saw people walk out of the room literally angry that he would even propose that. But, I thought it was great. Oh, and then there’s always Ken Thompson’s trusting trust paper about the compiler hack, which I love. 

For my USENIX lifetime achievement award keynote, I titled my talk “The fine line between bold and fringe lunatic”. It’s sort of about this struggle of picking a project that is sufficiently hard and challenging that you can really focus on intellectually stimulating stuff while minimizing the amount of drudge work (Dijkstra said this far more eloquently than I). In both the PASS (Provenance Award Storage System) and VINO projects there was a lot of drudge work. We had to rewrite the C library for VINO and we just did a ton of kernel hacking in PASS. It’s just not a good use of time. I try to avoid asking graduate students to do work that is boring and mundane and isn’t really going to teach them a lot.

A: You have received numerous teaching awards over these years. What are some of your favorite teaching moments?

M: One of the first courses I taught at Harvard was a big intro course. It’s now CS 50, I think. At the time, I changed languages and introduced the internet to CS 50. My husband has this saying: “who let these people out alone?!” when he sees somebody making a decision that’s extremely stupid. Halfway through the semester, I walked out of class and I was feeling pretty good about it. And all of a sudden, it hit me. “Oh my God, I’m one of those people they let out alone”. They just said, go teach our intro course. And I totally changed it. 

When I used to teach the operating systems course at Harvard, this is going to sound crazy…but, grading final exams in that course was always incredibly rewarding because, the students who three or four months earlier couldn’t have given you a concrete definition of an operating system are able to talk about real system design tradeoffs with a reasonably good level of sophistication. That is really quite remarkable. The fact that I can watch that transformation over three months is amazing. 

This isn’t traditional teaching, but there’s this moment pretty much with every PhD student where you’re in a meeting with them talking about their work and something happens and you just look at them and say, “Oh, you’re ready to graduate”. I vividly remember a student who was very polite and deferential. We were in a meeting and I don’t even remember the context, but he said something and I kind of teased him about it. And he turned around and teased me back. And I was like, “Oh my God, you’re ready to graduate!”. He was like, “huh?!” [shrugs]. It’s that willingness to be independent and being able to push back. That’s always a really fun teaching moment.

At Harvard, I was co-teaching with Radhika Nagpal (which is a ton of fun btw) when I learned to appreciate functional languages. It was a bizarre course. She was teaching the first half in Scheme and the second half we taught with C++. I never liked Scheme and never liked LISP or any functional language, but one of the assignments she was going to have them do was a babbler. Larry Summers had just given his infamous speech about gender and math. I wanted to babble Larry’s speech. So, I sat down to do the assignment and I was writing pages and pages of code. I pulled Radhika aside and told her that I thought the assignment was really hard. She looked at me and was like, “What do you mean? It’s three lines of code!”.

She thought nothing of the fact that you recreated the dictionary every time you added a term to it. Whereas, I was writing an update-in-place dictionary scheme, which is like a total “no no”, but it was this aha moment of like, “Oh, I really am not thinking about this right, am I?”. I was bringing my systems hat to the problem, and that was not the right hat to bring. So, I think that sometimes just working with students helps you realize all the biases you have. They may not be societal biases, but they’re most definitely technical biases. 

There was this student who always sat about three rows back and was really intense. I was convinced that this student hated me. It was really intense. And I was like, “I don’t know what I did wrong!”. It turns out the student and I are total buds at this point, we get along great. The intense look was just because the student was really concentrating and trying to pay attention. But, we bring these biases in, and we make assumptions about people that are totally wrong.

My favorite part is when students are able to either tell me I’m wrong or demonstrate something that I wasn’t sure they were capable of doing. 

Having spent my early teaching career at Harvard, I felt that the most important thing I could teach any of those students had nothing to do with computer science. It had to do with being able to say “I was wrong. I made a mistake and I’m sorry”. If I could teach them to say those things, I’d succeed. Unfortunately, though not intentionally, I ended up saying those things in class a lot, because I do make mistakes. 

One of my worst yet best lectures was when I was teaching a concept I had taught many times before. But, I just got really confused and I kept saying, “Oh no, that’s not right”. I kept trying to fix it. Within a few minutes, the whole class was working with me and trying to fix it. At the end of the class, I said I was going to think about it. And I did. But as I walked away, I realized that that class was more engaged than any I’d taught. I guarantee that every student in that class knows the concept way better than any other class because they actually tried to solve the problem. I thought, “so why am I up here lecturing, if that’s not how students actually get engaged and learn?”. I then started re-thinking my relationship with the students in the classroom. If I’m just standing there throwing information at them, it’s not very useful. It’s a bad use of our time together. So, I try to use that very sacred time effectively to help them dig into the material in a much deeper way than just saying “here’s what this program does”. 

A:  Moving on to interesting career transitions, you moved from Harvard to UBC and became the Canada 150 research chair. How did that come about?

M: One of my former students, Sasha Fedorova, reached out and told me that UBC was looking for a systems person. I said, “well, I can’t go anywhere before 2018 because that’s when my daughter graduates from high school”. They said they could be patient. So, we started what I like to call “dating”. I came to UBC and I interviewed and then we followed it up. This went on for quite some time, because I wasn’t doing anything until 2018. So, I like to say we dated for a long time.

I got this wonderful phone call in the August of 2017 where they asked me if they could nominate me for the C150, and I was like “yeah, that would be awesome!”.  By the time that came through, UBC was a done deal and I couldn’t turn it down. Part of why I like this department is also because the department was patient and gave me the time to decide what I wanted to do. They let me wrap my head around not just leaving Harvard, but leaving my home, my state, my country, and my kids. And that took time. 

[Stay tuned for part 2 of this interview which will be published next week!]

Bio: Akshitha Sriraman is a PhD candidate in Computer Science and Engineering at the University of Michigan. Her dissertation research is on the topic of enabling hyperscale web services. Specifically, her work bridges computer architecture and software systems and demonstrates the importance of that bridge in improving the performance, cost, and energy efficiency of modern hyperscale data centers. Sriraman has been recognized with a Facebook Fellowship (Distributed Systems), a Rackham Merit Ph.D. Fellowship, and was selected for the Rising Stars in EECS workshop.
She hopes to enter academia after her PhD program, and will be on the academic job market (for tenure-track faculty positions) this upcoming cycle.

Disclaimer: This post was written by Akshitha Sriraman for the SIGOPS blog. Any views or opinions represented in this blog are personal, belong solely to the blog author and the person interviewed; they do not represent those of ACM SIGOPS, or their parent organization, ACM.

1 thought on “People of Systems & Architecture: Margo I. Seltzer (Part 1)”

Comments are closed.