ACM ByteCast - Margo Seltzer - Episode 25

Episode Date: May 23, 2022

In this episode of ACM ByteCast, Rashmi Mohan hosts ACM Fellow Margo Seltzer, co-recipient of the 2020 ACM Software System Award (shared with Mike Olson of Cloudera and Keith Bostic of MongoDB). She is the Canada 150 Research Chair in Computer Systems and the Cheriton Family Chair in Computer Science at the University of British Columbia. Previously, Seltzer was the Herchel Smith Professor of Computer Science at Harvard University’s John A. Paulson School of Engineering and Applied Sciences and Director at the Center for Research on Computation and Society. She is especially renowned for her work on log-structured file systems, databases, and wide-scale caching. Seltzer was previously CTO of Sleepycat Software, developers of the BerkeleyDB embedded database, later acquired by Oracle Corporation. Among her many honors, she is the recipient of the 2020 SIGMOD Systems Award and was recently named one of the “Top 20 Canadian Women in Cyber Security” by IT World Canada. In the wide-ranging interview, Margo discusses her early years growing up in a high-achieving family and later studying applied mathematics at Harvard (before they had a CS major). She also recalls the amazing time in grad school studying under four legendary professors (including her advisor, Michael Stonebraker), and the origins of BerkeleyDB, which started as a graduate student open-source project and later became Sleepycat Software. Margo emphasizes the importance of taking risks and getting out of your comfort zone (and comfort research area) and inter-disciplinary collaboration, something she encourages in mentoring her students and junior colleagues. She also stresses the responsibility that comes with success and the value of mentoring students and providing guidance for impactful roles in service as well as research.

This is ACM ByteCast, a podcast series from the Association for Computing Machinery, the world's largest education and scientific computing society. We talk to researchers, practitioners, and innovators who are at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their visions for the future of computing. I'm your host, Rashmi Mohan. You know you've run into a very special guest when their list of teaching and mentorship awards

rivals their long list of accomplishments and awards for contributions to computer systems. Add to that a successful entrepreneur and open-source contributor, and you wonder, is there anything they can't do? Margot Seltzer is the Canada 150 Research Chair in Computer Systems and the Sheraton Family Chair of Computer Science at Harvard University's School of Engineering and Applied Sciences and the Director of Center for Research on Computation and Society. She has won the Usenix Lifetime Achievement Award for her groundbreaking work in databases and her company Sleepy Cat Software was awarded the prestigious SIGMOD Systems Award. She is an ACM fellow and was recently named as one of the top 20 women in cybersecurity in Canada. She plays soccer, she bakes, she teaches, and runs the world like a boss. What makes her tick? We're about to find out. Margot, welcome to ACM ByteCast. Thanks so much for that introduction. I hope I can live up to it in the podcast.

Oh, we're super excited to have you. And I'd love to lead with the question that I ask all my guests, Margot, which is, if you could please introduce yourself and talk about what you currently do, as well as give us some insight into what drew you into this field of work. I'd like to tell the story that I grew up in a fairly high-achieving family, unsurprisingly, and there was really only one thing I learned from an early age that girls were smarter than boys and that I was finally my family's opportunity to have the smart girl. For a long time, I had no idea that there were things like gender problems in science or any of those things because that wasn't the story that I'd been told as a kid. So my family is pretty mathy-sciencey,

and I was too. I grew up in a teeny tiny small town. I like to describe it that we had more cows than people. That is true. And then I went to Harvard for my undergraduate degree and was a little bit intimidated, to say the least. And so when it came time to pick what Harvard calls concentrations anyone else would call majors, I went through the courses of instruction, and they list like all the requirements for every major. And I looked for ones that were math and science and didn't have either a thesis requirement or a comprehensive exam, and you could still get honors. I want to be very explicit. I actually

do not advise either my children or my advisees or any of my students to use this algorithm. But it is in fact exactly the algorithm that I chose. At that time, Harvard had no computer science degree, but they did have an applied mathematics program, which had some computer science. And I had an older brother who'd done computer science. So I figured if he could do it, I could too. This is how I stumbled into a field that has become a profession and has served me pretty well for the past very large number of years. That's sort of the origin story. Where should we go from there? It seems to have worked out really well for you. I get what you're saying about don't use this algorithm today. I also wanted to know, what do you currently do? What does your role look like today?

So my role today is a little bit crazy, to be perfectly honest. I came to UBC four years ago, and part of my mandate was really to build up, rebuild a systems group that was, you know, starting to suffer some attrition. Many of our core faculty were starting to think about, you know, retirement. And so they were looking to rejuvenate the systems area. And largely, I was brought in to do that. So I'm in the same role I was at for the 25 years prior, but doing it in quite a different way. So I have many more students than I ever had when I was at Harvard. And I now have three new junior colleagues that I am mentoring. I'm super excited. I think they are really the people who are going to do the great

work at UBC. And my job is to support them in any way I can. We are, as part of that effort, we are trying to put together an industry consortium. And let me be perfectly transparent. I had a fabulous graduate school experience at Berkeley under the four superstars of Patterson, Katz, Stonebreaker, and Osterhout. And they had a fabulous setup with industry where twice a year we went and had these retreats. We got to know the really big names in our fields. They gave us feedback on our work. And I have actually wanted to reproduce an environment like that for my students ever since I became a faculty member. And I feel like we're on the verge of being ready to launch something like that at UPC

where we can give that experience to our students as well. So having been here four years, I decided not only to admit lots of students, but that I should be bold, which some people might interpret as crazy in my research, and really branch out into areas that reflected the interest of the postdocs I was able to recruit, as well as the students that I'm able to recruit. So I actually have research activities in areas that many people might not even think of as systems, but it's a pretty broad portfolio. So for example, I have a fabulously successful collaboration with Cynthia Rudin of Duke, and we do interpretable machine learning. And I like to say, you know, she does all the

hard math stuff, and I like to try to make it run really fast. But we've had a fabulously, just incredibly productive collaboration there. So she this week is giving a keynote at AAAI, we have a paper there, we'll have a paper coming out at AI Stats, we regularly submit to places like ICML and NeurIPS. And that's been tremendously fun. And I've gotten to learn a ton. So that's one area. I became really interested in program synthesis over the past seven or eight years and starting a project at Harvard that, again, you could either describe as courageous or crazy. And then based on that, we've done some more program synthesis here at UBC. I'm really interested in graph processing systems. So I have a bunch of

students who work on that. I was managed to attract a postdoc who has a background in real time systems. And so we've been collaborating with colleagues in the chemistry department who have a fully automated lab where they do chemical synthesis. And we're looking at security problems there. So it's sort of a cyber physical security angle. And storage is my bread and butter. So I have a couple of students who do work in storage. I have claimed for 30 years that I am not a networking person. And now I find myself working with a student who wants to do programmable network switches. So I have worked in that area too. And I'm probably forgetting a few things. But I think the higher bit is that I think too often we constrain ourselves to focusing in a teeny tiny area. And I think the most interesting problems really take place at the boundaries between conventional areas. So I've been trying to get rid of all those boundaries. That's incredible, Margot. I mean, that interdisciplinary work that you talk about,

you know, sounds amazingly interesting and probably opens up to so many other sort of, you know, collaborations for you. Do you feel like some of the, I mean, how does one, you know, what would be your advice? How does one seek out these collaborations? Is it typically from somebody like you're, you know, you're in charge of this program and, you know, you have this sort of ability to look for these opportunities because you believe that this is where the interesting work happens. How does one sort of train themselves in that direction? Or what would your sort of guidance be if, you know, one is train themselves in that direction? Or what would your sort of guidance be if one is not exactly in that environment? Like, how do we develop that skill?

I think the core answer there is an intellectual openness. And also, sometimes it's just finding the right people, even if you don't feel like they're working on exactly the problem you want to be working on. So when Cynthia and I started our collaboration, there was no thought in the back of my head that I am going to move into this area. I am going to actually make huge strides in machine learning. That was just not on the radar screen. Instead, it was Cynthia who was looking for ways to make her techniques more scalable. And, you know, I had students who'd worked on similar problems and we made software more scalable. And so it required that I reach outside my comfort zone.

I start to think about papers that have mathematical proofs and theorems, which is not something I'm super comfortable with. And at the end of the day, the key ability is the ability to be truly humble and ask what I like to call are the stupid questions. Because this was a new area, I didn't have any expertise. But I had a very trusting relationship with Cynthia, where I felt comfortable saying, I don't understand this. And it seems like this other thing is true. And sometimes those stupid questions would lead to really interesting breakthroughs for us. And similarly, there were the flip side happened where there were systemsy issues where we had a thorny problem to solve. And Cynthia would ask, you know, an innocent question.

And we'd all look at each other. It's like, oh my God, that's exactly right. That will help us solve this problem. I think the more senior you become, the more you expect yourself to know all the answers. And I think that's really, really dangerous. I think the naivete and innocence and willingness to ask what you think might be really stupid questions is actually incredibly liberating. And so I have really embraced, you know, working with students and saying, look, I do not know what you're working, you know, I don't understand this to the level you do. So help me come up to speed on it. And I think it takes a certain confidence to be able to say that. And then with that confidence, the ability to say, I just don't know, but I want to learn. And then with that confidence, the ability to say, I just don't know, but I want to learn. And I think that is perhaps the scariest part and the thing that

people find most challenging. That's an absolutely mind blowing, I would say, idea that you bring about, right? And I think it ties back to, again, I was listening to some of your other talks, where you talk about, you know, also taking risks, you are taking a risk when you go into this area that I mean, you've built expertise in a certain area over a number of years. And now you're going into an area that you're not that familiar with. So one, you know, I completely, you know, agree with what you're saying, which is you go in there with a level of humility and willingness to learn, but also with the risk that this may work out, this may not, we don't know where this is going to lead. And that risk, I remember you mentioning was, is easier to take when you're earlier in your career. Is that necessarily true?

Yes and no. I mean, the publisher parish mentality is absolutely there, especially with young faculty. And I think that that does breed a certain kind of risk averseness. And so as a young faculty member, I think that's really hard, because you want to go into a project with a pretty high confidence that something's going to work out. Now, if you know for a fact going in that something is going to work, then I would argue it can't exactly be research. But I think as a young faculty member, you need to go with the high probability projects, or at least many of your projects should be high probability. But I think there's always space maybe for a little bit of risk. And I think maybe the key is to practice taking risks, even at an early stage, not with everything. But, you know, at any point in time, maybe there's one somewhat, you know, risky thing that you're working on that if it pans out is going to be super exciting. And if it doesn't pan out, you'll learn a ton. Do you feel, Margot, that, you know, collaboration,

I know one of the goals that you have with this role that you've taken up is to actually bring industry and academia closer, right? Do you feel like the collaboration that you have currently with Cynthia, as you were mentioning, seems like more academic to academic collaboration. Other challenges that happen when you're sort of working with folks in industry and trying to solve a common problem that maybe, you know, one of you has identified? So Cynthia and I are very much an academic-academic collaboration. This issue of academic-industry collaboration is one that has really changed dramatically over the course of my career. So when I started in this field, there was a much blurrier line between academic research and commercial practice, at least in systems. And this was manifest in the conferences we had where you would have not only faculty trying to publish papers, but you would

have people who work in research labs, and there were more of them then. But you would also have product people. And the product people kept us grounded. So I like to joke that I'm not interested in solving problems that start with the statement if pigs could fly, because I've never seen the flying pigs. So having not only industrial collaborators, but industrial collaborators who embedded in the product space, that have to solve real people's problems, I think is crucial. And I feel that what has happened as our field has matured, is that the gap between research and product has become so wide, that some of the time I feel like those of us in academia are working on problems that are just not relevant today and won't be relevant for a long time.

And I feel that that has been a disservice. So one of the best experiences I had in graduate school was the biannual retreats that we used to have, where we got real feedback from real people. And sometimes it was like, yeah, that's never going to work in practice, do something better. And that was really valuable. And today, in some cases, comments like that, it's like, well, we don't care about practice. We're looking at the future. But I think that's a little bit myopic. I do have to talk about your graduate school experience, though. I know your work on the Berkeley DB, I mean, it was innovative and pathbreaking and is integral to your story. Would you like to talk a little bit about that and how it came about? Berkeley DB is in large part the result of what I like to call, you know,

dumb graduate student syndrome. I took a graduate database course from Mike Stonebraker, and I found one of the papers by Witwold Litwin particularly engaging. It was about extensible dynamic hashing. And this happened to coincide with when the folks in the computer systems research group, i.e. the people who brought you Berkeley Unix, were working on freeing up the entire user level suite of libraries and tools, which ultimately would enable an unencumbered Unix distribution. And so, you know, they needed replacements for lots of things. And one of the things they needed replacements for were the old NDBM package and the in-memory HSearch package, both of which were methods of doing hashing. And I was, you know, a dumb, naive graduate student. And so Keith Bostic, who at the time was my roommate, who's now my husband, and has been for many years, said, Hey, how would you like to, you know, do that cool stuff that you're reading about as a replacement for these packages? And I was like, Sure, I'll do that. As I said, this was dumb graduate student syndrome. As a result, so I teamed up with a fellow I had never met. This was back in the early 90s when remote collaboration was not necessarily a thing. And Ozan Yitnai, he was at York University, managed to build this hash package without ever meeting in person. And I don't think

we ever even spoke on the phone, but we exchanged a lot of email. And we put together this little hash package. And that was the beginning. And then Keith Bostic, who had in the back of his head had always wanted to use a, what he called a record manager to implement a new unencumbered version of VI, roped in Mike Olson, who had worked at a bunch of companies. And the first thing he'd done at all those companies was build a B-tree package. And Mike was currently a master's student working on the Postgres project. And Keith's like, hey, Mike, how would you like to build, you know, another B-tree? It's like, oh, my God, no, I've built so many of those. And then Keith convinced him that if he did it one more time, he would never have to do it again. So Mike bought in.

And so what happened was we had this hash package, Mike built the B-trees. Keith really did the architecture to give us a access method independent API on top of these two software packages. This was essentially the beginning of Berkeley DB. This got released as DB 185. It was shipped with 4.4 BSD. And then a funny thing happened, which is people started using it and people started using it in really scary ways. So we would periodically get email like, we're using Berkeley DB to store credit card data. It's like, it's not designed for that. It can lose data. There's no reliability. And Mike and I had done what was really an academic prototype of how to add transactions to Berkeley DB, which you can think of as providing sort of the core functionality of a relational database in a very different

package. And it was a package that would let you just link it directly into lots of applications. At some point, Keith and I got approached by Netscape. Those were the first browser people out of the University of Michigan who also developed an LDAP server, which became instrumental. Anyway, they were like, hey, that transaction stuff, whatever happened to it? It was like, no, no, grad student code. But at the end of the day, they said, you know, we'd really like a transactional version of Berkeley DB. And this is something Keith and I, having now been married for a while, decided we'd really

like to build. And essentially, we crafted a deal with Netscape, such that we could do this work we really wanted to do, we would retain rights to it. So we could try to go sell it to others. And from a personal level, if we never sold another copy, we'd be really happy because we'd produce some good technology. And so it was on the basis of that deal that we started a company because, well, there was actually a house we owned and we didn't want to bet the house. And so we formed a company. And then after we got the first release of the product for Netscape, we hung a shingle out, which in those early web days meant you built a website.

And lo and behold, other people wanted to buy it too. That's the Berkeley DB origin story. There were a couple of strategic decisions that really enabled BDB to be what it was. The first was that we structured this deal with Netscape so that we never had to take any external funding. We were not looking to become rich. We didn't want to work with venture capitalists. It was, this is enough money to let us do this project in what I like to describe as the second 40 hours and build a piece of software that we really cared about. So we didn't start out with these world domination expectations. And I think

that was crucial. The second piece is that Keith invested a huge amount of time talking to lawyers and other people who had open source libraries and figuring out how we could maintain Berkeley DB as an open source product that would be available to the research community and to anyone else who was building open source and yet provide a foundation that would let us have a business that generated revenue. And so I think we were, if we weren't the first, we were certainly one of the first to really have a dual license business where we had an open source license. And yet we also had a business where we could make money by selling licenses to people. That was all Keith's hard work at getting the right license and making that happen. That's some pretty, you know, I would say,

you know, visionary sort of, you know, work there, because, like you mentioned, it was not very common. Although I do want to ask you was the idea of staying self funded? Was that common in those times? I mean, I know today, you know, you think about startups, and you think about one of the first things after you have somewhat of a viable product is to go out and seek funding to be able to scale to be able to hire to be able to scale, to be able to hire, to be able to do all the things that you want to do. So was that decision unique for those times? Oh, heavens, yes. It is still possible to build applications in your basement. But when you say startup, that's not the stars that show up in people's eyes. They want the

prestige of being venture funded and working with all these big names. And we were sort of the antithesis of that. And in fact, my own PhD advisor at points during the history of Sleepy Cat told us we were idiots for not going out and taking venture. And then when the boom of the early 2000s became the bust, he then thought we were brilliant for having this open source dual model. And I'm pretty sure that we didn't actually change our intellect at any point. We just really, we were really invested in building a cool product, not in getting rich. And I think a lot of people let the lure of fame and fortune cloud their decision making,

even today. That's amazing to hear about how you made that conscious choice, and you were able to stick with it and build this product out to the vision that you had for it. ACM ByteCast is available on Apple Podcasts, Google Podcasts, Podbean, Spotify, Stitcher, and TuneIn. If you're enjoying this episode, please subscribe and leave us a review on your favorite platform. For you personally, Margot, you did make a transition from running this as an open source product into a business

and then being the CTO while also balancing your academic career. That's no mean feat. So how did you do it? I mean, I know you mentioned 80-hour weeks. My heart stopped for a minute. But what else are we missing? I've mentioned the little bit crazy part, right? You know, we didn't know exactly what we were getting ourselves into. And it really was both of us had day jobs when we started. And so it was like, do all the work for the day job, which in my case meant try to get tenure, and then figure out what cycles you have for the night job, which is how to get

Berkeley BB into a stable version that we could sell. So it was totally insane. I don't actually recommend this for most people, but we were younger then. This was pre-kids, although we did have our first child only a year or so after starting the company. Not necessarily my recommended parenting advice either, but it seems to work out. That particular child has now become a trusted colleague. It's fabulous. So it was crazy. It was insane. I wouldn't advise anybody to do it, but it was the right thing for me to do at the time. It's, you know, it is our journey. And when you look back at it,

of course, you know, you have a different vision of or different view of how things would have played out. But it sounds like it worked out really well for you. But speaking of tenure at Harvard, Margot, I did read that you were only the second woman to gain tenure at Harvard. What was that journey like? So I was the first junior woman promoted from within in the entire what is now School of Engineering and Applied Sciences was the Division of Engineering and Applied Sciences at the time. The first woman was Barbara Gross. She was hired in as a tenured professor. She was wonderful and fabulous, and I'm sure I couldn't have gotten where I got without her. So there were a couple of firsts in there, like when I had to explain to my dean that I was about to have a baby.

Unlike my male colleagues who could show up at Christmas parties with wives who were eight months pregnant, you know, that was not an option for me. It was going to become very apparent that there was a child on the horizon. But I have to say, you know, my dean was amazing. So I go in to break the news. And he's like, so you know, what do you want to do? And I said, Well, my plan is that the baby's due in December. So I will co teach in the fall, I will front load my responsibilities so that, you know, when the baby arrives, my colleague can take over. And then in the fall, I will front load my responsibilities so that, you know, when the baby arrives, my colleague can take over. And then in the spring, I will come back to work with the baby in tow. And I'll be able to teach my course in the spring. This was in the days before

reasonably decent parental leave policies and stuff like that. So that was the plan. And he was like, Okay, like, really, that was it? And so I brought a baby to work for nine months. And my colleagues, for the most part, were amazing and wonderful. There were several moments where colleagues just said the right thing. And I cannot emphasize enough how important it is for senior people to say the right thing. And so the two that really stick in my head, one was Barbara Gross, who was running a faculty search. We were a tiny department, and she was looking for people to go out to dinner with candidates. And I said, look, I'm happy to do it. But like, you know, the little guy's going to be in tow. And she said,

well, that's fine, because we wouldn't hire anybody for whom that was a problem. And it was like, wow, okay, like, that's really cool. And then I'll never forget the other one. So Michael Rabin was my esteemed colleague, Turing Award winner, awesome person. And when my son was four weeks old, I decided that I would venture into Cambridge and have lunch with my colleagues. Casual lunch, nothing official. So I walk into the room, and it's all the people I feel comfortable with. And so I'm not stressing about being like, oh my God, do I breastfeed in front of like, what happens? And so I fed the kid beforehand anyway. And I get in there, and it's all the people I feel comfortable with, the other junior faculty and Barbara's there. And then Michael walks in. And of course, 30 seconds later, my son starts to indicate that he is hungry. And, you know, mentally, I'm going to be like, do I leave and excuse myself? Do I like wrap blankets around my head and body so I can, you know'm bringing the kid to work, like, this is going to keep coming up. So we're just going to feed the kid. So I had my lunch, he had his. And as we're leaving, Michael stops me and he says, what are your plans for next term? And I'm thinking to myself, like,

oh my God, here we go. And I said, well, actually, I'm going to bring the baby to work. And he's like, oh, that's wonderful. You'll be able to be with him and we'll still have you back and I was speechless and grateful and a little choked up if you can hear and I actually got to tell Michael that story recently he is long since retired but I was visiting him in Jerusalem and I made it a point to tell him just what a huge huge impact that had So the message to all you senior people out there is that your words matter a lot. And judgmental ones will devastate your junior colleagues and supportive ones will be remembered 25 years later. You know, honestly, Margot, the way you describe it sounds like a dream, at least for most women out there, right? It is a real struggle. And the

kind of challenges that we face are just not those that our male colleagues might face, especially when you're talking about, you know, feeding the baby, taking the baby with you. There's just not any way that a partner could do some of those things. But you know, what I love the most is that you've taken those experiences in your life and really, and maybe, you know, this was something that you always believed in, but you also have taken it to actually be a huge proponent of inclusivity. I've heard some of your talks around how you're challenging your colleagues to exercise that muscle and really create environments that are inclusive of all kinds of diversity. Would you like to share

some more about that? I've heard it, but I would love for our listeners to hear more. So I guess not everyone had the same experience I had. And I think it's really important to make that clear. There were individuals who were truly, truly supportive of me and for whom I will be forever grateful. That doesn't necessarily mean that institutional support exists and that institutions are necessarily supportive of people. So I have junior colleagues who spent their pre-tenure years in the same institution and had very different experiences. And personally, I tried to be the person who was there to support them. And I watched kids for some of my colleagues when they had to teach. I had colleagues whose children were the same age as mine, and I would take them out and do things so that my colleague could get work done.

I don't think we've solved the problem. So there's all the data. Women are still doing more of the service work than our male colleagues. Too many of my male colleagues use their paternity leaves to do startups. There are huge problems, and it's hard to give up privilege. I get that. At the same time, it's even harder to not have the privilege. And I think we all need to acknowledge the privilege that we get and be grateful for it while at the same time trying to pass that privilege along to the folks who might not be getting it. And I don't think we're yet at a point where we do that really well. I agree getting it. And I don't think we're yet at a point where we do that really well. I agree with you. And I think that's an incredibly powerful

statement that you made. It is hard to give up privilege. We all have privileges in, you know, different ways. It is hard to give up, but to constantly sort of examine and make sure that you're aware of those and making sure that you're putting out a fair playing ground for everybody is so critical. Is there something that, you know, both organizations, you know, whether that's, you know, in academia or in industry can do, you know, culturally to actually improve this, you know, any thoughts that you might have that you feel has worked? Well, I sure hope we can because otherwise we're in a pretty dire situation. So I think the first thing is acknowledging when we mess up and being able

to say, wow, we messed up. And I think that is the first thing that most institutions are totally incapable of doing. In establishing a new lab at UBC, I actually got a chance to build culture from the ground up. And I did it intentionally and thoughtfully. My former colleague, Radhika Nagpal, who's now at Princeton University, had a bunch of great resources about how she did that in her group. And I borrowed heavily from her resources. Yuri Alon has materials on how to nurture scientists. I created an environment where the culture and the way we interact is as important as the research we do. And we try to have really open conversations about it. So, for example, a year ago, I was on the Turing Award Selection Committee. And unbeknownst to us, we ended up honoring someone who had made very, very hurtful statements, particularly towards Iranian students. And I happened to have pretty much all my new students were Iranian. I had, I believe, four graduate students.

And when this came out, I was out to every single one of both, not only my students of Iranian descent, but also any of the other students in the lab. And I said, look, this is happening. I can only imagine how terrible it who took the time to do that. But I think it's that kind of empathy, a word we don't use in computer science very often, unless you're designing in jest, but have cut my students to the bone. And I think we can't expect ourselves to be perfect, but we need to hold ourselves to higher standards and we need to take responsibility when we mess up. And I think that combination of transparency and humility are really essential. And I feel like both of those are in somewhat short supply in our field. I think that's just to highlight again, acknowledging when we make a mistake and asking what we can do better. I know those two things that you mentioned are so valuable and can really make a difference in the life, career journey of anybody who's in that situation where they're not the sort of the stronger group. You're talking about life lessons, Margot. One of the other life

lessons I heard when I was listening to some of your talks was when you said something that you took away was, it's all my fault. When I first heard that, I was like, hmm, how does this play out? I heard it. I thoroughly enjoyed what you said after, but I'd love to hear from you. How did that come about? So I believe that came about after one particular semester where I'd just taken on too much, and I was burned out at the end. And I was trying to figure out how to like take back control of my life. And what I realized is that I am in a privileged position, to a large extent, in that I do have control over what I do and don't do. Now, not everyone does. So I hopefully will have time to come back to that.

But I certainly do. And so the, you know, the mantra, it's all my fault, is really designed to remind myself that I can say no. And so it was really about prioritizing things I was willing to say no to and things I wasn't. And for me, things that were simply to bolster my prestige or ego or standing were much less valuable than things that were directly going to help my students. And so even today, when I am stressed out and overworked beyond belief, the one category of request that I never say no to is from a student. Like, I need to talk to you. When uttered by a student is an imperative.

We need you to do this thing that'll be really good on your resume. That is not an imperative. And I've been trying to also inculcate in my, you know, my junior colleagues, like what are really good uses of their time and what are not good uses of their time. Because as a community, we are horrible at just asking people to give time for things that are really not very good for them when they are junior faculty. And many of the junior faculty are like, well, but you know, I'll get to know people and do this. And it's like, no, not this way. There are better ways. So, you know, it's all my fault means when you have agency and can make decisions about how you're spending your time, then you should use that agency to make smart decisions.

Now, when you don't have agency, then it's a whole different story. And, you know, the reality is that one of the major causes of you are someone who can't control your surroundings, you are still privileged because we are in a profession where there are jobs and we are in high demand. And if your job is too stressful, you do have the one option of going and finding another one. And I think sometimes that's such a big leap that we don't realize that it might be the right solution.

And when I was listening to your talk about this and what you just mentioned as well, I think what is really powerful and stands out is that it really takes away the helplessness, right? It puts you in control of the situation to say, if it's my fault, then I can actually fix this, right? And I can actually make these decisions hard as they may be. Like you mentioned, it's not always easy to make these really difficult decisions, but at least it is a choice that we have. And you're right. I mean, in our industry, we do have a lot more choice. It's not just about comparison to other industries. We definitely have it a little bit better in terms of just, you know, the ability to choose how we work and what we work on. I wanted to definitely talk about your passion for soccer. I heard about that in so many different forums. Please share with us,

why is it such a, where did that develop and what have you been doing with it? That's great. I can actually pinpoint it to a couple of key moments. I did not grow up playing soccer. I worked for a company, my, let's see, this was the third year out of graduate school. I worked for Stratus Computer. And there were a bunch of people who got together to play soccer. And it was the young folks. And so I wanted to socialize. And so I started playing.

And I discovered that the sport was kind of fun. I'm not particularly wonderful at it, but it was fun. And so I went and I found a women's team in 1985, I think. I joined this women's soccer team, Charles River Women's Soccer Club, and I played with them between 1985 and 2018 when I moved here, except for they gave me a five-year leave to go to graduate school. I got to experience what it was like to have a large group of women friends, which as a computer scientist, I had really never experienced. And Charles River or the Chucks as we like to call ourselves were amazing. And these are some of my closest friends still. And you know, they were my tribe. And when I got tired of working in the male dominated field that

was computer science, I had these women to support me. And I like to tell people we've been through births and deaths and marriages and divorces and everything in between. So that was how I got into soccer. Now, the real passionate fandom I can trace back to when the Women's World Cup came to the US in 1999. I got tickets to a game in Foxborough. And I'd never been a huge spectator sport person because I didn't really get it. Because most spectator sports were like, people who looked nothing like me. And I was standing at the game and the US women took the field. And there was this wave that rolled over me. It's like, oh my God, these are people like me. I mean, they're way better than I am, of course, but they're doing something I really enjoy at a level that is amazing. And it was a transformative moment.

Now, because this happened in the middle of the World Cup, I of course did not have tickets to go to that amazing final that we all remember. But I did decide that like, this was my thing. And so when inadvertently, the World Cup came back to the US in 2003, I bought tickets to the final and the semifinal. And I took my women's soccer loving son with me, and we had the weekend of a lifetime. And ever since then, except for the, I think 2007 was in China, I did not go there. But ever since then, the World Cup has just been a thing that I do, increasing fervor over the past decade. So the last two World Cups, I've basically caught every US game. I tried to catch most of the Canada games last time and was a little thwarted because they got eliminated sooner than they were supposed to. But I got up at five in the morning to watch the USA Canada game, knowing that regardless of the outcome, I was going to be pretty happy. I'm really excited with how the Canadian women have been doing this year. I think it's amazing. So I had a soccer team in Vancouver before I had an apartment. And the Strikers,

which are my local team, are every bit as wonderful as the team I had in Boston. I am sadly out of commission at the moment because I'm waiting to get my second hip replaced, but I fully expect to be back on the field about a year from now. That's wonderful. And you know, your passion just comes through shining. So we wish you well. We hope that you're back on the field and enjoying the game very soon. This has been an incredible conversation, Margot. For our final bite, I'd love to know, what are you most excited about, you know, in the field of surface systems or the research that you're doing over the next five years? That's a really hard question. I mean, realistically, what I am personally most

invested in is seeing my three junior colleagues that we've just hired do amazing things. And I don't care exactly which amazing things they do, but I'm really most invested in making sure that I can provide the support that they need to get started. And then also to really graduate my first cohort of PhDs from UBC. And those are likely to be in areas of storage and information systems and networking. And so I will continue to work there and support them so that they can go on and do awesome things. It's so obvious why those wonderful teaching mentorship awards have come your way, you know, truly spoken like a guide and a mentor. Thank you so much for taking the time to speak with us at ACM ByteCast. My pleasure. Thank you. Machineries Practitioners Board. To learn more about ACM and its activities, visit acm.org. For more information about this and other episodes, please visit our website at learning.acm.org

slash b-y-t-e-c-a-s-t. That's learning.acm.org slash bytecast.