Claire Le Goues

Women@SCS conducted an interview with Claire Le Goues, an Assistant Professor in the Institute for Software Research department at the School of Computer Science.

So could you tell us a little bit about your background and where you're from?

I grew up outside New York City about 35 miles north, right on the river. So between the Tappan Zee and the Bear Mountain bridges if you know your New York suburbs. There's not much there, but it's really pretty in the fall.

My parents are actually immigrants, they came from France. It's funny actually, they came to Pittsburgh --it was their first city in this country and my mom did a masters and PhD in materials science at Carnegie Mellon; she came on a one year scholarship and just never left. They moved to New York, they got jobs there, and that's where they are now, and that's where I grew up with sort of a traditional suburb upbringing I guess. Then I went to college, I went to Harvard so I moved to Cambridge, MA, which is actually where I worked before going to graduate school. I did graduate school at University of Virginia, which is in Charlottesville. It was very beautiful, a little humid. People from the actual South will dispute that its the South, but its the South to me. It was good and fun, and now I'm here, so that's the story.

So you worked for a year “in the real world” at IBM, what made you ultimately choose academia?

That's a very good question. So I worked as a software engineer and I mean, it's just a completely different job compared to that of an assistant professor in a tenure track research position. It's almost difficult to compare the two, right? Because you just do different things. But you know, I enjoyed it. I was working for a division of IBM, I was in software, but the group I worked with was a very recently acquired startup called Data Power, which was fairly well-established by the time they were acquired. And I mean “very recently acquired,” like they moved into their offices in the IBM lab the same week I started. So, they were acquired and there was all this time with the acquisition to sort out the deals, and they started at IBM the same week I did. So it actually had a lot of the flavor, I think, of what it was like to work for them before they were acquired, except with probably better benefits, (though I can't speak to that since I didn't work for Data Power previously), and a lot more meetings as they tried to figure out the integration. By and large, at least when I worked there, upper management let them keep doing what they had been doing. So they had the same processes, like I was on bug duty once every six weeks.

And what's bug duty?

When you have a commercial software product, most times, many products have bug report databases where users and developers submit bug reports, and then it depends on the company how they're managed. But a practice, and one that Data Power practiced at the time was that every developer who worked for them was on bug duty once every six weeks. So you dealt with bugs in the bug database, and bugs were assigned to you and you had to fix them. I don't know how much of that practice was maintained as they were integrated further. I sort of think of it as more of a startup thing, but it's possible other groups at IBM did the same thing.

But for example, a lot of the development at IBM is done in Java in Eclipse, they had a lot of investment in Eclipse and so on. But Data Power had been developing in basically C++ and using emacs on the Linux machines, since they were a startup and that's what they did. They kept that tool chain when they moved to IBM so it wasn't quite your standard IBM engineer position in a lot of ways, at least in terms of tool chain and so on.

I was going somewhere with this story... anyway, I liked it, it was fun. But I got the impression at the time that I would be happy there for a while and work as a software engineer, but in about ten years, Ii would have wished that I had gone to grad school, but by then it would be too much of a pain to go to grad school, because you know, you get promoted, you buy a house, etc. It's harder to leave the older you get, so I was like, “okay, I should clear out now before it becomes too hard to go.” So that's why I applied so quickly, because I figured out pretty quickly, “oh, this is fun, you know. I like to build things, I like to code, I like to engineer... I just will not want to be in this role forever, so I should go before it becomes annoying.” I prefer research, I like doing science. I like the first twenty percent of a problem a lot more than the back eighty percent. It turns out in shipping software, there is an awful lot of stuff you need to do that is not solving the original problem. To turn the solution of the original problem into something you can sell to people, there's a lot to do there. I was on bug duty, I was trying to fix unicode encoding for Ukrainian character sets or something like that because we had an Ukrainian customer and there was something broken. And I was like, “okay, so I understand why this has business value, and I understand why I'm supposed to fix it and why it's important, but this is not the part of the solution that I like,” and there are people who love that, right? People who get really excited about unicode actually. But you know, it's the nitty gritty details of making a system work, and there's people who love that stuff, who stay up on bug duty until midnight like it's their favorite thing. I prefer prototyping and figuring out the first solution. I like experimenting, I like making hypotheses and testing them. The other thing was, I did more theoretical programming languages research in my undergraduate program, and then working as a software engineer, you see firsthand the problems of software engineering. Some of that is just working on a system with an overnight regression test suite, with the build chain as complicated as the Data Power products was, it totally changed my focus, like “wow, we have not figured out how to engineer software. Somebody should.” So those things combined, plus me saying, I will not want to do this when I'm thirty,” I went to grad school. So that's why I left. But that's why I do software engineering research now, mostly because you see it in the real world and it's very different from at least what I learned about in school.

So how did you decide to come to CMU?

It's kind of a funny story. Interestingly, I don't know how much you know about the faculty job search process if you come out of grad school. Okay, so I didn't post-doc. I got my PhD in May and so now I'm here. But whether or not you post-doc or not, the search process is sort of the same. It's almost like applying to school in that there are sort of deadlines or dates by which schools start accepting applications, and you write certain types of essays, and a cover letter, and then you have your resume, and then you have letters of recommendation. The only difference between that and applying to grad school is that not all schools are hiring, obviously. Some schools are hiring for faculty that have expertise in particular areas, like there are research institutions that are looking for somebody who does computational biology specifically and they'll say that in the ad, and I don't do computational biology, so I'm not going to apply there. There's a bit more variety, so it depends what kind of program you're looking for and what kind of faculty member you want to be, and you don't have to pay application fees, at least not in computer science. So it basically feels like applying to grad school or college --you're sending out applications before the day, you have to make sure your letters get everywhere, and you send everything off into the void, and then you wait. Because if you're not getting an interview, they're probably not going to tell you until like, July. Bear in mind you send these out in December and if the schools tells you they're not going to interview you, which most of them don't, it's like July. So it is the halting problem, right? Because you're just waiting to see if somebody calls. It's interesting because the timeline varies considerably between departments based on their academic timeline, and the faculty members who sit on the committee and what their other schedules are.

So my first interview was probably the last week in January, I don't remember, something like that, and the Institute for Software Research invited me to interview in April. So it was a very long process for me and CMU was the last school to call, which is not good or bad, it just threw a wrench into the proceedings because I was very surprised. Because CMU is such an amazing school for computer science, I almost didn't apply because I was like, not that I think badly of myself, it's just such a top ranked program. You know? Who knows what they want? But my advisor made me, so listen to your advisors I guess is the lesson. And I'm glad I did.

So I came after a number of my other interviews, but I had a great time. I think part of it was just that I was so delighted to be invited, I was honored to be nominated basically that I wasn't even that nervous because I figured it wasn't going to happen. I was just like, “I get to meet these very established people in my field, the faculty here are amazing, like they invented software engineering. So this is a great opportunity to get to go and have interesting conversations with people, who cares about getting the job?” At which point, I wasn't really that nervous, which I think helped because I could enjoy my interview over the two days. You present, and you meet with students, and you meet with faculty between an hour or a half hour and you have this conversation about research and where you see your research going, what kind of directions you want to go in, and what's your tenure plan. Your vision basically, and their vision. And it's a lot of fun, at least it was for me. I had really great conversations here, I felt like I was really pushed, and to think critically about the kind of science I'm interested in doing, and what kind of program I want to set up, and what kind of research I want to do. So I thought it'd be a great environment, and you can just tell just by talking to the faculty it's very stimulating. And I mean, CMU is number one for a reason, and one of the things I like about it is that I could be in the Institute for Software Research, which is a smaller department, but it's inside this much larger community of the School of Computer Science, which has like 200 faculty. So it's kind of all the benefits of a small department with all the benefits of a big department. Like there's 1000 people to talk to, but we have our little bubble of software community which is nice.

A lot of things went into this decision, depending on the size of the department, there'll be a certain number of people who do research that's even moderately similar to yours as a faculty member. It's extremely rare to have this many people whose interest is just software. Which is part of the thing, CMU is huge, computer science is huge. So there's a lot of people that are doing software of some variety. I thought that was really cool, there's all these people who do what I like, it's really interesting.

Then, I like Pittsburgh. There's various family considerations, my husband's family is in central West Virginia, so it's very convenient for them. My family's in New York, it's a direct flight, so there was a little bit of that. So there were a lot of considerations, there were a lot of good opportunities here, great support for faculty, the students are really smart, which you can tell just by talking to any of them for five seconds, you can tell they're sharp. So the whole package - I had a great time at my interview, I was very stimulated. So here we are.

So you just said it's a really nice town, what do you think of the weather here?

So I've only been here for two months and the weather's been great, but I am from the northeast and I've spent many years in Boston.

Is that worse?

I think it's less cloudy, but my understanding here is that it's cloudy here six months a year. I will predict that the winters are worse in terms of it being colder and there being more snow. Some people are like, “oh, you're from Virginia, you're not going to be able to handle the winter,” but I grew up with winter so I can handle winter. I think you lose it after a while but you get it back. I'm going to need to buy new boots or something.

Now that you're here what are you first impressions of Carnegie Mellon as a whole?

I mean it's sort of the honeymoon period, right? So largely positive. Everyone's been really nice. Carnegie Mellon has a reputation for being a pretty collegial place for faculty members getting along and helping each other, you know what I mean. And so far, I have no evidence to contradict that, which is the short version.

So far, everyone's been really nice, and students have been sharp. I have all the things I need except for this stupid shiny screen, but I made that mistake, that was me, I picked that and now I'm regretting it, so I really can't blame CMU for that. So far, so good. And the weather's been great over the last two months so I really can't complain about that. Ask me in March, I'm sure it'll be a different answer, I'll be like, “I miss the sun! But not the humidity.”

Can you tell us a little about ISR and what kind of research you do currently?

Sure! I am certainly not the expert in the history of ISR, and so I don't want have it be the gospel, so there's basically two halves, there's kind of the core software research side and then there's COS, which is Computation, Organizations, and Society. I'm on the software research, not COS side. I feel it's weird to say it's ISR and COS, but I think, I know we're the same department, but I'm on the ISR side in terms of core software engineering faculty. COS, they do a lot of cool stuff there actually, studying social networks and human networks. They don't have an undergraduate minor, which may be why you guys don't know about their research as much, but they may be moving in that direction. It's sort of a group of faculty whose research focuses a bit more on humans and society. For example, another new faculty in ISR is Yuvraj Agarwal who sits over there, and he focuses on energy efficient computation, and he fits in because of the societal implications. They tend to do work on networks, so social networks, networks of developers, different teams who work together. It's kind of a catchall, looking at how people organize themselves, how they communicate, the societal implications. I'm not on that side at all.

I focus on software quality and on fixing bugs in programs specifically. But I have these larger concerns about the fact that we build a lot of software. In the last 50 years, it's this amazing transformation we've undergone in that software now runs the world... and it's super broken, and it's always been super broken. It's interesting if you read some of the foundational research literature from software engineering from the 60's and 70's, they have intro paragraphs that are very similar to intro paragraphs that I might write, like, “Software systems have become so complicated, programmers have a hard time writing them properly, they're full of bugs. This is an issue,” and it's still an issue. On the one hand, it's kind of encouraging because we've built all these systems that run the world pretty effectively despite the fact that they're full of bugs. On the other hand, it's a little nerve-wracking because the entire economy is predicated on programs that are just, I mean, full of bugs, right? For various reasons.

So I worry about that and I worry especially about the software that we have and how we can fix it. And what we can learn from the ways that we have broken it and the ways we can fix it to build new systems in the future that are better. So, this actually has a bunch of meta prompts to go to with it. So I told you, I worry about software quality. What does it mean for software to be high quality? That it's not broken right? It's really hard to measure, it turns out, and one of the things I worry about a lot is whether a change to a program is good. Because most software these days, I mean, you should break software into regular software and safety critical software. Stuff that flies airplanes don't change all the time because they have a whole bunch of systems of generating provably correct code so that planes don't fall out of the sky, and that's very good. But it's also very expensive, so we can't do that for like, Chrome, because we just don't have the resources.

Fine, I worry about the things, (I also worry about airplanes), but the kind of problems I'm talking about right now, I'm talking less airplanes and more operating systems that we're running on our desktops, programs that we're using. And those are changing all the time because developers are constantly changing them, they're generating newer features, they're making them better, they're refactoring, they're fixing all the bugs, right? So they're checking in stuff to the code all the time. So if I have a change that a developer made, is it any good?

It's more like open source right?

Yeah, so I tend to study a lot of open source projects, just because I can. But there are a lot of similarities between the way open source projects are developed and the way that proprietary software is developed in terms of the systems they use and their processes. So, I'd like to be able to look at a change to code and tell you thumbs up, thumbs down. How do we do this? I don't know. And you know, there are some, I'm not the first person to say like, “hey we need to measure software quality, but I want to know what it means for software to be good, especially in the face of change.” Because software's always changing and the environment it's running in is always changing and its users are always changing and coming up with new ways to use it. And even if I could prove in a mathematical way that it's totally correct today, tomorrow that proof is meaningless because everything is changed. And so I worry about software quality in the face of change. Of late, what I've been doing is fixing bugs automatically. So you have a test case that's failing in your software, I work on techniques that cause it to pass without breaking everything else.

Is that what the GenProg project is?

Mhm, and that's the GenProg project. So GenProg uses stochastic search techniques, genetic algorithm in particular, to evolve a patch, like a small set of changes, to fix a program while maintaining its other functionality. And it works pretty well in practice, or so I would claim (I have some evidence to back that up). So yeah, GenProg stands for either genetic programming or for generic programmer pair, depending on when you ask me. So, we go back and forth on that. That's what the GenProg project does: fixes bugs in existing systems by searching over the ways we can change them in an intelligent way.

How did you become interested in this whole bug-fixing area of computer science coming from a more general undergrad education in CS?

So, there's a bit of a trajectory there. I always really liked programming languages. Those were some of my favorite classes as an undergrad. And the reason I like it is that it combines sort of theoretical prettiness, basically--so things that are satisfying to me in a theoretical and mathematical way--with practical analyses. So a lot of the goals of program analysis for example is to help us reason about programs so that we can write better programs and we can prove things about them and so on. And I like that because there's a practicality to it because we're dealing with programs and code that humans write and use in the world, but it's backed up by math in a way that I find satisfying. So that's why I started there. And then, like I said, I worked for a company with an overnight regression test suite. So I was like wow, it's a whole different world. There are plenty of analyses that work very well on 50 line programs, but how do you deal with these systems that are so huge. Like, if everybody would formally specify their code when they wrote it, things might be a lot better, but there's an awful lot of code that already exists that is not formally specified. Like, how do we deal with it?

And so I'm still very concerned with how we write programs that are good and how we know they're good, but I think I sort of changed the scale at which I was operating when I sort of saw the scale at which industry often operates. And there's still a very, I like to think a program analysis-like flavor to the kinds of problems I find interesting. I think there's still a connection to the more theoretical programming languages, stuff that caught my eye many years ago. But I've kind of reframed it, or it's been reframed by my experiences with real world code. And I forget what the original question was... you ask me why I got here, how I got here from undergrad. So I think I answered it...

So I guess being in industry for a year helped you to focus your research more?

Probably more like 18 months. But yeah, I started with the thing I sort of found interesting. I had to take a bunch of classes as an undergrad and then these were the ones I liked the best for whatever reason and then my experience with real world programming shifted my focus a little bit. So I still like program analysis; I still use those techniques a lot, or I'm inspired by those techniques a lot in the kind of stuff that I research. I've just moved a bit more into the engineering side and a little bit away from the math side.

I think a lot of students in CS right now just don't know exactly what they like in CS, so do you have any advice for current undergraduates who don't exactly know what is out there to explore?

So I actually wanted to be a lawyer. My first year-and-a-half of undergrad, I studied social theory... and I think I turned out okay, haha. There's certainly value in knowing what you want to do, but it's not the end of the world if you don't. I think it takes some time to figure it out. I think it's okay to go work in industry for a while and see if that works for you. I would encourage undergrads to take a variety of classes, honestly, just to see which ones you find fun. Maybe you take a machine learning class and you think it's super fun. Then you can stop and reflect, okay, why is this fun? Because maybe it's fun because you had a particularly good professor and it's fun to take classes with good professors. Maybe it's fun because there's something about the underlying theory or the applications that is fun. And then you can start to synthesize what it is you like. But I think I would just encourage to take as broad a set of courses and sort of expose yourself as much as possible to the different options that are available.

I think especially at CMU, you have so many options available. I mean, really, any class you'd want to take, any subject in computer science you want to know about, you can learn about it. So, the best way I think is to just taste a bunch of different foods and see which ones you like. And, don't worry about it if you don't know right away. I think a lot of people do know right away, and those people make the rest of us kind of feel a little, at least me, a little neurotic. Like, “oh, I should know.” But I didn't know when I started. I switched majors, super hard. I was reading Habermas, and Max Weber, and all this really heavy social theory, which I still love, don't get me wrong. Then I started taking intro to computer science. So, I changed majors, super hard. I think it's fine to not know what you want to do. I think the way you figure it out is by trying a bunch of stuff and seeing what sticks. And if you're not sure if you want to do research, try industry for a while. But, if you have the opportunity to try research, try research too because they're very different. So, take advantage of the opportunities as they are presented, I think.

What would you say is your favorite part of research?

There are a couple different ways you can answer that question. I really like working with smart people and I think the academic research community is very vibrant. There are a lot of really smart people running around. I like bouncing ideas off of people. Computer science research is very collaborative, which is not true of all research communities in the world. There are other disciplines in which this is less true but certainly in the more systems oriented computer science resource kind that I do, collaboration is extremely common. So I like working with other people and that exchange of ideas you get when you talk to other people and the different perspectives.

And then you get to solve a new problem that nobody's solved before by joining forces and forming Voltron. I think that's really fun. I like solving problems that no one's solved before because I feel like you're expanding the bounds of human knowledge. I feel like I'm talking all the fluffy stuff, but it's true, I like this. The problems I'm dealing with, they've not been done! And that's fun. I like the freedom. The nice thing about being a professor who does research is you kind of just set your own agenda. I still want to build a particular research program; I'm not going to do a random thing in this area, a random thing in that area. There's a set of problems that I tend to be focused on because that's my expertise, but when it comes to my daily job and my daily job, I have a tremendous amount of freedom in what kind of problems I want to tackle and who am I going to work with today and what am I going to do today.

I like--this is sort of a scary moment--when you have a question, like, okay, I hypothesize that the readability of the code is related or correlated with the likelihood it contains a bug. That's not really my research but I'm borrowing from a friend of mine who's studied some of this. So this is a proposition that you can study statistically; you can measure the readability of the code, you can find a bunch of bugs in the code, and you can see if the two are correlated. So I tend to use the R programming language to do statistics. So you read in the data and you say like whatever it is dot core and then you have the data frames to get the correlation and it comes out and you see the table of the numbers. And when it's statistically significant, at certain levels, there's different levels of stars at each row, because it'll say, here's the correlation between these two factors, and a bunch of statistics and then it says the p-value. And so three stars is the best, well at least in terms of p-value. I really like when you do that and you're a little nervous because you have this hypothesis and you've collected all this data and you could totally be wrong. And you get the data out and you look at the stars, and you are right. I love that.

I like it when you find things you didn't expect. So, long example here from this hypothesis that we had for a long time. There was an underlying assumption that informed a lot of the work on GenProg... I was totally wrong. It didn't invalidate our results; it wasn't like I made a horrible mistake in setting up my experiments and everything I ever said was wrong. It wasn't like that, it was more like we predicated certain design decisions on a belief about buggy code and it turned out it worked out. We can still fix code with this assumption, but we never really examined it in any depth. So we have a lot of data now and we can examine this in depth, and so I start looking at it, and you look at the data, and we were like, we were wrong. We were super wrong. And I had to check it like six times before I went and talked to my co-authors because you don't go to your co-authors and say, hey this thing we believed very fervently for a long time is wrong. But I like that. I like when you go look at the results and you see something unexpected, and you're like, huh, that's weird, I wonder what that's from. And then you have new questions. It changes every day. That was a rambling answer. I like my job; it's fun. I like to teach too. I like to advise, so that's a good time.

Are you teaching currently?

I'm not. I will be teaching next semester. So at the graduate level, ISR has a core course on sort of the fundamentals of software engineering research for the PhD students in the ISR program where we cover methods and techniques and foundational work and papers and so on in software engineering research. It's taught in modules to cover the many different areas of software engineering research. I'm doing one module so that's like three or four lectures, so it's not exactly teaching. I mean it's teaching, like, I will be teaching three or four lectures, but it's not a full course. Next semester I'll be co-teaching a master's class with the MSE program and I'll probably start teaching undergrad classes next year, we'll have to see. Depends on what needs to be taught and who's available to teach it, and so on. But I do like to.

So what are some of your hobbies and favorite pastimes?

I actually do roller derby, which is probably the most surprising answer I can give you. Most people are like, “professors do roller derby?” So yeah, that's my big one, that's what keeps me off the street. I started that in grad school in Charlottesville. It turns out there's a league in Pittsburgh. They're really good, actually, so the all-star team in the Pittsburgh league is top 20 in the world, basically. I don't skate at that level; I sort of play JV, but it's a really fun sport. I don't know if you've ever had a chance to watch it. It's super fun. It's actually a fun sport to play and it's a fun sport to watch and it keeps me off the streets. And I'm not good about getting exercise sort of without a reason. I'll start on gym habits and then quit after three weeks because I feel like a gerbil. Doing roller derby is really good exercise. It's also a nice way to meet people. Other adult humans in the world, especially outside of academia. I like my colleagues, but it's nice to meet people from all walks of life and roller derby--it's a very big eclectic group of people. So, that's fun. I like to cook. I like to travel--actually, another really good part of my job.

Where have you traveled?

Most recently I was in St. Petersburg, Russia for a conference. It was really cool! I wasn't sure what to expect in St. Petersburg, but it was August so the weather was really nice, which helped, and I had a really nice time. So, I was there for a conference in my field. Basically two leading conferences which I'm most likely to attend. And because conferences attract people from all over the world, they vary very much in their locations. And actually, a lot of the big conferences, at least that I'm familiar with, try to alternate. They try to keep to a schedule where it's one year in the U.S. or sort of the north western hemisphere, one year in Europe, and now, actually, more are trying to do U.S., Europe, Asia, to sort of be fair. That way, there's not one group of people who always have to have an 18 hour time difference. We all have to suffer equally.

Somehow, the two big conferences in software engineering that I typically attend--they're in far flung places over the next few years. After Hong Kong, next year's ICSE is in Hyderabad. And I think they're both in Italy the following year? Which is not standard. It sounds crazy when I say that. The conference that was in Russia, just now--last year, it was in Cary, North Carolina and it was hosted right next to NC State. So it sounds like I spend all my time jetting off to Hyderabad, which is not actually true, it's just by coincidence that in the next couple of years, the conferences happen to be in exciting faraway places. Not that there's anything wrong with Raleigh, it's a nice place. It was actually very convenient for me so I drove. So it's a nice part of the job; you get to go to new places.

If you go to grad school, I recommend you get a miles card--you know when you get frequent flyer miles: you figure out wherever you go, you figure out the major airline, the services, whatever airports are near you, and get frequent flyer accounts because you go to conferences a lot, especially in computer science. Because computer science is different from a lot of other fields in that it's a conference model more than a journal model. So most sciences publish journal articles, which have a much longer time frame. It takes like three years to publish something. It's true in computer science too; we have journals and conferences aren't the primary mechanism for distributing results. Computer science is different in that in most areas that I know of in CS, we focus almost exclusively on conferences. Which is kind of funny because when you talk to other people who do other kinds of sciences, they're like, “conferences...?” They'll go, but it's not their main focus.

But I think because computer science is young and it moves very quickly compare to physics, which has been around for hundreds of years, we're still doing this fast-paced conference thing, and so there are lots of them, so it's exciting. Most fields have more than one a year. Not all of them — but software engineering does. So, I like to travel — I do it all over the year. I like to cook and I like to eat.

Lately, I've been trying to explore Pittsburgh a bit. Getting into house stuff — we bought a house. Turns out, my husband's super handy. He actually retiled the third floor bathroom and installed the sound system on our first floor.

Have you found any nice places in Pittsburgh?

We live in the center of Squirrel Hill and I like it there. We went Downtown the first time this weekend and found ourselves in Market Square, kind of by accident. I found it really charming. We also saw the Giant Rubber Duck. Point Park is also really nice. We also went to the National Aviary once. We have a parrot — actually it's my husband's parrot. He likes birds and that's why we went to the Aviary. It's actually a very nice aviary. There are big open rooms and birds will eat out of your hand if you're patient. I also went to the Cathedral of Learning this weekend and saw some of the international rooms. We're doing all the standard tourist stuff that you do when you move into a new place and people come to visit you. I also went to the Phipps Botanical Garden. It's huge and lovely. It's my favorite. And the lunch at the cafe there is really good and they have free wi-fi too. I like Schenley too. I walk through Schenley Park when I don't feel like taking the bus. But I haven't seen a third of it yet — so I'm working on it.

My mother was here this weekend — like I said earlier, she went to CMU too. And she likes to walk a lot. She came back from a walk one morning and said, “I don't think I spent nearly enough time walking through Schenley Park when I was a student here. I don't know what I spent my time doing, but I definitely wasn't walking through the park.” So, let that be a lesson to you! My mother was at CMU for four years as well, just like you, but she was doing a grad program.

What is your favorite quote?

I'll tell you the one I put in my dissertation. It's something Marie Curie said once. She didn't say it in English, but it roughly translates to “One never notices what is done, but only what remains to be done.” Which, I think, serves as a sort of reminder to me to stop once in a while and notice how far I've come. It's my effort to remember to appreciate the accomplishments that I have made — like finishing a paper, for example. Do the same with homework!

If we were to pit Harvard, UVa and CMU against each other, who would you root for?

Well, it depends on the competition. An interesting question here is, “What is each school best at?” It's kind of hard for me to answer because I experienced each environment in entirely different contexts. I did my undergrad and Harvard and really loved it. It was also really good for me. Graduate school is completely different from undergraduate. So, I can't compare the undergraduate experience at Harvard with the undergraduate experience at UVa, because I wasn't an undergraduate at UVa. And they're both completely different places. UVa has 15,000 undergraduates and it's a state school. I loved Cambridge. I liked Charlottesville too, but it's a small town.

And again, I'm faculty at CMU, which is completely different from being a grad student and deeply removed from being an undergrad. So, it's really hard for me to say. I definitely see more robots walking around here, which is really cool. UVa would definitely win at football. It's really hard for me to comment on this, since they were all really different places. I have no idea what it's like to be faculty at Harvard!

I believe Harvard has a focus of a different kind. I think they have a division of engineering and applied sciences now. I actually have a Bachelors in Arts and Computer Science because there wasn't any other school at that time, which was relevant. Thus, I have a more liberal arts background and took a lot of classes that I wouldn't necessarily take at an engineering school. In UVa, computer science was in the engineering school and the engineering graduate program was completely different from the non-engineering graduate programs. So, yes, they're very different places.