Running a Lab using Discord

Graduate school is a challenging and sometimes isolating experience in the best of times; during COVID, I worry that it's particularly so. As a professor responsible for both my own students and the greater systems student community, I worried a lot about the impact that COVID was going to have on our students. 

From March to May, like half of the rest of the world, we adopted Zoom for group and project meetings, with each group having its own meeting. Unfortunately, since these were all on my account, that didn't help too much, because if I'm in a meeting with Project A, the Project B folks can't use the Zoom room for their project. This was definitely suboptimal.

We also used Slack, but I have something like ten different slack channels and I found that keeping up with it (and just remembering to look at it) was a challenge. 

At the end of April I was co-chairing a conference (Eurosys) and after consulting the coolest people I know (my kids), I decided to try using Discord to simulate a hallway track. We introduced it late and not a ton of folks used it, but the few who did convinced me that there was enormous potential, so shortly after, I switched the lab to Discord (since the other faculty member was on sabbatical, I felt like I could make the decision somewhat unilaterally).

We've been using it now for about three months, and I'm pretty happy with it. I did a survey after a month or two and also got (anonymous) student feedback. So I'll try to both report on why I like it and try to summarize the student's response.

How we set up the server: 

Since this was an experiment, I kept things relatively locked down. Faculty have admin powers and everyone else can participate fully, but not really administer the server. (It wasn't that I didn't trust people, I just wanted to run a bit of a more controlled experiment.) 

We created a schedule channel where we could keep track of weekly meetings.

We then created pairs of text and voice channels for each project group.

As we started to arrange group social events we created a text-base social-event channel and a voice-based Watercooler, which gets used for grad students to hold Office Hours for the undergrads (an initiative completely undertaken by the students).

Some conversation on the general channel resulted in our creating a channel on technology, law, and government regulation.

We created channels on which to have follow up discussion from our weekly reading and writing groups. But mostly, we tried to keep the number of channels down to a dull roar. (I'm guessing that when new faculty start and return from sabbatical, we might introduce some hierarchy around the projects, just to keep the list of channels more compact.)

My reactions

1. It's an integrated "place" where I can engage in both asynchronous text-based conversations and synchronous meetings/conversations. I think it would be nice if a voice channels could have text components, so we didn't have to pair two separate channels (i.e., I'd prefer something that looked more like Skype with its message channels). But the integration was important for me -- I could keep one "thing" open and watch that thing.

2. There is visibility into what the different projects are doing -- if I see that my Project A folks are meeting a lot, that could either be a great thing or it could be a sign that something is up -- it lets me ask.

3. There is also social visibility -- if you see people hanging out at the Watercooler, you can join in, just as you might do in real life (and if people want to have a private conversation, you can do that via direct messaging).

4. I really don't like the fact that in order to construct a group direct message conversation, I have to be friends with the people; it's not sufficient that we're just on the same server. This is a pain and is probably my #1 feature request.

5. I go back and forth about whether I like the fact that direct conversations are globally scoped -- that is, if I have a conversation with Arju, that conversation is not part of any particular server (organization), it's just a conversation with them. In contrast, on Slack, I can have a conversation with Arju as a TA for my course or as a member of my lab and those are entirely separate. Initially I preferred the Slack model, but I may be coming round.

6. A few folks seem to have more difficulty with video calls on Discord than they do on Zoom. I don't quite understand why -- I find that all seven thousand of the different communication platforms I use sometimes get confused about who owns my microphone and speakers and which one I'm using, but it doesn't seem to be Discord specific.

7. Changing between Discord channels is WAY better than moving among Zoom breakout rooms (I'm pondering use of Discord in class).

8. High order bit: to me, our lab server genuinely feels like a place and community to me. It feels like it does a moderately good job of creating an atmosphere for our lab. The combination of Discord and our overall lab culture has allowed 'visiting students' to feel welcome and part of the community and to develop a sense of our culture. This may be possible with other platforms as well, but it seems that Discord has worked particularly well for that.

General student feedback

Slightly over 70% of the students reported that Discord was either fabulous or good (split evenly).

17% were neutral

13% were negative (split evenly between "don't particularly like it" and "really don't like it").

Creating a positive lab culture

Although I attended my very first NeurIPS this year, I missed the keynote by the incredible Celeste Kidd. Fortunately for me, she shared her closing remarks, which I encourage everyone to read. She says important things far more eloquently than I and raises issues that frequently go unspoken.

Inspired by her words, I want to talk about the proactive, constructive part of the story that we as professors, advisors, and/or managers can do to create a healthy culture in our labs and offices. Much of what I share here I have learned from my amazing colleague, Radhika Nagpal. She too has deep insight and material on creating a positive lab culture.

Let's start with the obvious. Lab culture is important; it's what we live and breathe every day. When I moved to UBC, I decided to explicitly write down what I hoped to achieve in terms of lab culture. My website says,

Lab Culture People do their best work when they are both challenged and happy. Research provides plenty of intellectual challenge; our lab culture is designed to encourage happiness.

We are open and collaborative We value diversity in all dimensions, welcoming students and collaborators of all genders, orientations, races, and religions. We collaborate within the lab and with colleagues outside the lab. Today, we have projects with colleagues from theory and engineering, statistics and business, Harvard and Duke, the UK and New Zealand, colleges and high schools.

We are positive Feedback is critical to the research enterprise. However, feedback can take many forms – we welcome constructive criticism. We criticize ideas, not people. We criticize with respect. We are open to others’ perspectives. We do not always agree, but when we disagree, we do so collegially and respectfully.

We are supportive Each of us shares in the mission to enable every member of our lab to achieve their greatest potential, realizing that each person’s definition of success is highly personal. We support each other in realizing our individual images of success. (Radhika Nagpal’s awesome talk articulates this eloquently.) We do not tolerate personal attacks and discrimination of any kind.

The part in italics comes directly from Radhika.

Here I'd like to talk about concrete steps I've taken to try to create that culture.

Day 1 -- My first face to face meeting with a student

For the past five years or so (it took me a long while to figure this out), I open my first conversation with students with the following.

Welcome!  We are so glad you are here. You were admitted, because we believe that you have what it takes to be fabulously successful in our program. That said, graduate school can be hard and there will be times when things aren't going well. It may be your research; it may be something personal; you may be unwell. No matter what it is, do not hide. You are welcome to come in here any time and say, "I didn't get anything done this week."  Just do not hide. Come to class; come to lab; come to our meetings. Together, we will get through this.

I like to think that this is the first step in establishing culture. It says that the students are not alone and that my job is to help them get through this big, scary ordeal they are starting. It is my starting point at building a trusting relationship.

Lab 1 -- our first lab meeting of the year

We began the year by welcoming back all our continuing students, welcoming our new students, and welcoming our visiting students. We then played the game where each person wrote down, on a sticky note, something about themselves that they thought others would not know and that would make them unique. I then read each one and the group tried to match the statements to people. This turned out to be a lot of fun. We were terrible at guessing!  You have to make up rules about people telling the truth (i.e., if I say, “This must be you Juanita!” and it is, you have to fess up).  We tabled the harder ones and came back to them.  I think I would probably use some physical sorting during this to keep people moving and to separate those “still in play.”

Next we spent the thirty or forty-five minutes talking about what an inclusive environment looks like and what behaviors make an environment not feel inclusive.

I shared memories of my first days and weeks at UBC and how students and faculty alike went out of their way to make me feel welcome and included. I also shared stories of a conference I'd attended recently where I was invited to one of their VIP events and felt incredibly unwelcome and most definitely not included. Other students shared their experiences.

We have  a diverse international group and better gender balance than many computer science and especially systems groups, so we heard many perspectives. People were thoughtful and respectful.

Lab 2 -- one week later

I had given people homework to take any two Implicit Association Tests. I also shared my favorite quote on the topic, "Being biased doesn't make you a bad person; it makes you human. Being unaware of your biases and/or being unwilling to work at mitigating them is what makes you a bad person."

I admitted that I always test biased against women in science. I asked how many people found their results uncomfortable. Then I talked about the specific things I do to try to compensate for my biases, e.g., blind grading, the conversations I have with myself before meeting a new student.

Then we played a two-minute video from here.

Next we played The Tag Game. This did not work as well as I had hoped. I labeled the tags with numbers of stickers of different sizes, shapes, and colors and then asked people to form groups. They were all kind of lazy and just formed groups as a function of where they were standing instead of looking at the name tags at all (but maybe this was a sign that my group didn't need this game?).

The basic idea is that people focus on finding people with similar shapes and/or colors on their nametag and when you see the patterns, you can start talking about how you were drawn to finding others like yourself and what this means in other contexts.  So, even though the game didn't work, we had the conversation anyway!

Then I  talked about different kinds of bias and let the conversation just go from there — fabulous interaction! Some of the biases that came up:

• Gender bias
• Beauty Bias
• Affinity Bias
• Conformity bias
• Halo bias
• Horn bias

Lab 3 -- one week later

I came in with a stack of sticky notes on which I'd written one-sentence scenarios, all of which were based on genuine interactions that I'd had with students. These scenarios ranged from health problems to family problems to stress reactions -- some were pretty intense. And I warned people that some of the topics might make them uncomfortable.

The students paired up and each student took a sticky note. Each student got a chance to both be a student dealing with the issue on the sticky and a student to whom someone was coming for advice. Here were the directions:

Each person is going to grab a sticky and then with a partner, you'll take turns being a student who is experiencing some difficulty or a friend that is being asked for "help". You'll get about 5 minutes in that role and then you'll switch; we'll do this with about 3 different partners.

Every one of these scenarios is based on a real conversation I've had with students (or former students).

As the listener: Your first task is to figure out what the person wants:

• to vent
• advice
• help
• something else

Many of these are problems you cannot "fix" -- this is sometimes frustrating and uncomfortable as an engineer. Figure out what your partner wants/needs and what you can do (sometimes it's just getting them to talk with someone else). As the person in difficulty, think about:

• How do you ask for help?
• How scary is it to ask for help?
• What do you want (see above)

After each person had had a few different partners, we had a group discussion. It went really well. Students acknowledged just how hard it was. A colleague said that they'd found themselves using words that they weren't used to using in conversations with students -- FEELING words. Some people were confronted with situations to which they couldn't relate, e.g., I'm male and my partner was dealing with a pregnancy. Even so, we talked about how to be a supportive colleague even when you can't empathize.

I expect that we'll do a similar sort of orientation/culture-building exercises this year, but we will talk more explicitly about racism. We'll talk a lot about mental health -- COVID-19 has changed our lives in myriad ways, and I worry more than ever about students feeling isolated. I moved my lab to Discord about a month ago, and it seems to have been a good move. I spend a lot of time on Discord, Skype, Zoom and make sure that every one of my students (almost) has some structured time to talk with me every day -- it might be short; it might be in the context of our reading group, but for the students who want it, they can have daily human interaction. At the same time, many of these meetings are optional, so the introverts don't need to feel overwhelmed.

Advising Junior Colleagues

About two and a half years ago I wrote a blog post about advising grad students. At long last, here is Part II in my (very slow) advising series. It addresses the question, "What do you tell your Junior Colleagues?"

Let me begin with a disclaimer: I can't guarantee anyone success. When I talk to my junior colleagues, whether at Harvard or elsewhere, I tell them things I really believe, but (unfortunately) I don't make the rules, I don't make decisions, and what I believe may or may not be right for any particular person or institution. So, this is my opinion on what I think one should tell Junior colleagues. But hey, this is my blog, and everything in it is just my opinion.

Let me just start out by putting it bluntly: being a professor is a bit of a crazy profession. It's one that has worked for me and offers many features (perhaps the topic of a later blog), but it's not the kind of job any sane person would make up. You get into this job because you're used to being really good at everything you do. Unfortunately, there are way too many things for a professor to do that you can continue to do all of them at the same quality level that makes you comfortable This is perhaps the greatest challenge that we have to face -- be willing to do things at less than peak performance. I repeat, "You must be willing to do some things at less than your peak performance." This seems totally counterintuitive in a highly competitive job, where you feel that everything you do is highly scrutinized, but if you try to excel in everything simultaneously, you will drive yourself totally crazy.
So, what is an over-achiever to do?

Pick and choose carefully. The key here is that you can't do everything well all the time. Instead, you pick what you are going to do well at any point in time. As an academic, I like to think in terms of semesters. At the beginning of each semester, you have to decide which are the things for which you need to produce A work and for which can you slide through with B work. Each semester, the lists change slightly so that at some point, every functional area gets some A work and some B work and every semester gets some A work and some B work.

Let's make this more concrete.

Let's say that you've just started your first faculty position and you want to make a good impression -- how do you get started? My advice typically goes something like this. No one expects you to crank out much research your first year. If you have some straggling papers from your dissertation or post-doc, that's fantastic -- get those out. But, your real focus in year one is to get your teaching under control and get your research agenda planned. Note that planning a research agenda is different from doing research, but we'll get to that in a minute.

If you are in a kind department, then you can assume that you'll be teaching the same courses for several years. That means that if you invest time this year in developing your courses the way you want to teach them (i.e., you make teaching an "A" priority), then you can leverage that investment over the next several years (expending "B" effort, while ideally obtaining "A" results). So, while many will tell you that any time you invest in teaching is wasted, I disagree. Good teachers get good students. And good students will help you do your research. That said, invest time wisely. Time spent automating grading is time well spent. Time spent developing four thousand step animations is not. (And trust me, it is very easy to fall into this trap. I've done it.) I could go on for quite some time about what is and is not a good use of your time with respect to teaching, but that's another topic. For some detail, I recommend my colleague Harry Lewis's article on the topic or my more recent experience elsewhere in this blog.

And then remember that what works for me may not work for you. The key ideas are:

1. Figure out what works for you.
2. Invest time in things that are reusable.
3. Remember, the quality of your teaching is best measured by how much the students learn, not how entertained they are or how much they think you or your slides rock.
4. True learning takes place when students do things and get feedback -- anything you can do to improve the quality of feedback students get on work increases the chances that students are actually learning something.

Sadly, most students never look at anything other than the final grade on massive assignments. I spend hours grading final papers and both writing and typing up detailed comments. Few students actually read these comments, so perhaps it's not a good use of my time. However, I still do it, hoping that perhaps one of them will actually learn something.

OK, so picking up the main thread here -- invest time in your courses in year one so that in the next two to three years, you can teach the same courses with minimal effort. You hire good teaching assistants, you pull out your notes (and perhaps assignments) from the previous year and you spend almost no time preparing. Sure, in those future years, you're giving a B effort in teaching, but because of the prep you did in year one, you ought to be able to invest B effort and get A- or B+ results.

The second part of year one is planning your research program. That probably means figuring out what you want to do and then writing the proposals to get funding for those projects. This is the time to renew acquaintances with all your friends who are now working in places that fund academic research. See if you can get some supporters lined up for corporate grants -- these are small grants, but require significantly less effort than your classic NSF grant. You'll want to submit one or two of those as well (and I mean one or two, not six or eight), but your main goal is to have a plan for the research you want to do and convince people to give you money to do it. If you have your ideas well in place by the end of the first semester, that puts you in good shape to identify the grad students you want to admit.

Getting a handle on what projects/research you want to undertake also sets you up in semester two and over the summer to write high quality grant proposals. This is the time to squelch your inner procrastinator. Get your proposals written early enough to get feedback. Ask your senior colleagues for critical review -- if you are in a good department, they want you to succeed and will help you submit the best proposal you can. It's also worth teaming up with another colleague or two for some bigger proposals if (and this is a big if) the work necessary on the larger project is compatible with that research agenda you spent so much time crafting. Don't lose sight of that.

So, if all goes well, by the end of year one, you will have lots of reusable materials for your teaching, a research agenda on which you can begin to execute, a couple of proposals in the pipeline, and some incoming grad students whose interests are well-aligned with your research agenda. Begin year two.

Year two is all about getting your research firing on all cylinders. Over the last several years I have become a strong believer in knowing what paper you are writing when you begin a project. If it's real research, then you had better not know the results, but you had better have some hypotheses. Write those down. Really. Honest, write the opening paragraph that motivates what you are doing and why. If you can't write it now, why are you doing the research you're doing? Sure, you don't know how it will turn out, but if you don't have an hypothesis, you don't really know why you're doing what you're doing.

Concurrently with getting that research started, you're also starting to be a graduate advisor. That is a whole other topic, but in the context of this discussion, the message is you have to realize that this is another one of those activities that you need to learn to do. And every student needs a different advisor -- you might be able to play that role for multiple students, but if you walk in believing that you can advise every student identically, you will not be a successful advisor. You need to have some basic advising methodology and a philosophy, but you need to get to know your students, understand their strengths and weaknesses and figure out how to most effectively advise each student. This will take time.

After year two, you should be a on a role of focusing mostly on your research and students, and then periodically having to step back and brush up your teaching (i.e., make it an A task for a semester or two), whether to update a course, update your teaching methodology, teach a new one, develop a new course, translate your course to the web, etc. However, if you use that time effectively, then you can still make research an A priority for many of your semesters. Do not confuse grant writing with research -- grant writing is a necessity (at least in my field). If you are successful, you can secure several year's funding with a semester or two of concentrated effort and then forget about funding for awhile. However, you have to keep track of where you are in the funding cycle and know when it's time to elevate grant writing to an A activity, so you don't suffer from a gap in funding. Personally, this is a huge challenge for me as I'd much rather do research than write grant proposals (I'm kind of guessing I'm not alone here). As a result, I can end up leaving grant writing a low priority for too long -- don't let this happen to you.

Now, some of you are getting ready to scream at me and say, "What about all that other stuff? What about program committees and NSF panels and guest lectures and attending conferences and departmental committees, and undergrad advising and all those other things that our institutions expect us to do????" If your colleagues aren't already ready to fire me for saying that you can sometimes relegate teaching to a B activity, I'm sure some will cringe at the next section.

High order bit: you do not have to do as much of this stuff as you think you do.

There, I said it. Seriously, the closest I've ever come to "yelling" at my Junior colleagues (you know who you are) is when I see they have signed up to do six program committees in one year. Yes, program committees are useful. Yes, they keep you up to date on what people are doing. Yes, they get you known. But six? No! It's not a good use of time.

My advice is no more than two program committees each year. One of those can be a real conference and one can be a workshop. Yup, no more than two. And you don't have to do two every year, but repeat after me, "No more than two." There, wasn't that easy?

Now, how do you pick the two? You want to work your way up to getting on the program committee of the big conference in your area. It needn't happen in years one or two, but by year N-1 (where N is the year you are up for tenure), you want to serve. In the meantime, build up your PC credentials by serving on the slightly less prestigious venues. Pick workshops that are very closely aligned with your current research agenda. It's fine to approach current chairs and let them know that you'd like to serve on a future committee -- they will pass it along to the next chairs (of course, if you already know who the next chairs are and they've not yet put together a committee, you can approach them). You can also ask your senior colleagues/mentors to help you get on the big program committees. However, your best approach is to accept a limited number of invitations and do an outstanding job. Get your reviews in on time, engage in thoughtful discussions, be positive, etc. Trust me, you'll have more invitations than you'll know what to do with. But now you know what to do, say, "I'm really sorry, but I'm completely booked up this year on program committees -- please let next year's chairs know that I'd be interested though."

Note: I do not always heed my own advice, and I almost always regret it.

OK, that's program committees, what about NSF panels? I find that serving on those is extremely helpful right before I am about to submit a proposal, because they remind me how panels work and what's important in a proposal. So, you should do a few of these, but not a lot -- perhaps one every other year? That feels about right to me. And yes, you'll get asked to do more. Fortunately, those invitations are always accompanied by specific dates, so you can use your, "Oh, I'm so sorry, but that day/week/month is simply not possible for me."

How about committees in your own department? This is a bit tricky. If you are in a nice, nurturing department, they won't ask you to do too much, because they don't want to distract you. However, there are some committees that are worth the time -- in my opinion graduate admissions and hiring. The former because it gives you firsthand knowledge of the pool and puts you in good recruiting territory. The latter, because you know who's coming out in the few years after you, who you might want for colleagues, and at whom you should be looking. However, moderation is your friend -- don't do both in one year -- each of these is very labor intensive (admissions a huge burst at one time in the year; search a more steady time sink throughout the year). Just like with your PC invitations, you can be polite and constructive in turning down committee invitations, "Dear Chair You-Who-Controls-My-Destiny: While I would be very excited to serve on the suck-all-my-time-out-of-day committee, I'm afraid that I cannot do it this semester/year. I've already scheduled all my committee time on other activities. I would however be happy to serve next year (and will reserve time now if that's feasible)." What's a chair to do? They can't really dispute what your schedule looks like and you have, in fact, signed up to do it next year. Of course, if it's an activity that you feel you never want to do unless someone is holding a close relative hostage, you'll need to tweak that letter slightly and leave off the part about wanting to do it in the future.

Finally, there are those friendly invitations to "Come give a talk." Giving talks is a good thing; it can be fun; it gets you visibility and gives you a chance to find out what's happening in a department. But, it also takes time and means "yet another trip." So, be strategic. There are times during your pre-tenure years that giving talks is more important: the semester before your department is going to write to every researcher on the planet asking their opinion of you. Yup, the year before tenure and, if you have a formal mid-tenure-track review, the year before that. Even then, you do not need to give 4000 talks. Be strategic. You can probably guess at least half of the people to whom your department is likely to write. Pick the very top departments from that list. Rather than visiting every institution on your list, leverage the most prestigious departments in your field. Be visible -- maybe, just maybe, if you're up for tenure, you give the talk rather than having your student give it. Even if you don't do that, use your conference time wisely: talk to colleagues, let them know what you're up to. Invite them out to lunch/dinner with your students. Finally, rather than traveling to give a talk, you can ask your department to invite them as colloquia speakers. It's funny how many invitations I get to come give talks that are followed up a year later by letter requests. You think it's purely coincidence? I don't.

The other way to make sure people know what you're up to is to convene a mini-workshop on YOUR RESEARCH. You have to get this right, but if you have the funding and can really take advantage of the event and you can persuade people it's worth their time, there is nothing better than inviting 15-20 bigwigs in your field to spend a couple of days at your institution engaged in thoughtful, interesting conversation. If they also happen to come away with the big picture of your research agenda, won't you feel like the star? I believe that it is becoming more common for departments to allocate at least some funds to help you do something like this. It can save you a lot of travel.

Above all, learn to say, "No." You can be polite, but you must be firm. After one particularly brutal year, I adopted the mantra, "It's all my fault." The message to myself was supposed to be that I control my work life and if I'm too busy, it's because I've said yes to too many things. Surprisingly, rather than being a defeatist attitude, it's actually quite empowering. If it's all my fault, then I have the power to change it.

One of the trickiest things for me is saying no to students. I truly love spending time with students -- after all, if I didn't like students, why would I choose to be at a University? When they invite me to a faculty dinner, I'd love to go, but guess what. Dinner time is family time in my life. I already miss way too many dinners when I travel and I frequently have some child-transportation responsibilities in the late afternoon or early evening, so it's quite difficult to really make faculty dinners go. So, what do I do when students ask? Typically I explain that evenings are rough for me, but suggest that we do lunch -- either during the semester, or more frequently during reading period when both our schedules are a bit more flexible. This past year, I had evening duty in Cambridge with one of my kids and that let me attend a faculty dinner or two or use those evenings to take students out. Yes, it cost more than a faculty dinner, but the students are more interested in just hanging out with you and talking than with trying the local 5-star restaurant (should you have one). The hours I've spent over lunch, dinner or coffee with students are among the most fun of the semester -- it doesn't matter if it's in the formal setting of a faculty dinner. In fact, think of the faculty dinners as mechanisms for you to figure out which students might enjoy just chatting and then do that!

OK, those are the things I like to tell my colleagues. Some have found these words useful; I'm sure others will find that they don't work. In any case, you get to make decisions about how you spend your time. If you make those decisions wisely, so that they simultaneously help you be productive and keep you sane, you will either end up tenured or you'll end up not-tenured, but reasonably content with your life, instead of bitter and resentful.

Margo's Tips on Writing a Thesis

I advise students on writing theses. Sometimes these are my own students; sometimes they are students at Harvard working with other faculty; sometimes they are students who needed an external committee member. I figured that if I wrote down my philosophy about theses, then such students would know what they are getting into before they ask me. And maybe, others will find this useful as well.

I believe that it was my former student, Keith Smith, who first introduced me to the idea that every paper (and therefore every thesis) is a story. Before you write anything down, you'd better make sure you know what the story line is. The story line will help you pick your chapters, write your introduction, keep you focused, and potentially entertain you. Some students have a hard time thinking of their very serious research as a story. Somehow it feels demeaning to them. Well, I make it worse. I suggest they actually think about it in fairy tale terms -- that's right, start with, "Once upon a time," and end with "happily ever after." It may not be a morality tale, but ideally it will be a technical tale. So, the first thing I might ask a student inviting me to be on their committee, "What story are you telling?" Be prepared to answer that question.

In addition to being a story, a thesis is a piece of writing. As a piece of writing, it should be technically correct. That means that you apply the basic rules of grammar, you run spell check, you strive to make the writing as elegant as the research. This seems obvious, but you'd be amazed how many students think of writing as some secondary process. The best theses are those that allow me to focus and think about the ideas (and story line), rather than the fact that every sentence makes me want to pull out my red pen.

There are things that tie together these first two items. Avoid being redundant and saying the same thing more than once (yes, that was intentional). I know that you are trying to simply staple N papers together and call it a thesis, but as a reader, I don't need to read about the same piece of related work five times. I also don't need to be told twelve times that your system is the most wonderful piece of technology ever created. Think story line. Most things will fit nicely in your story line once; figure out where that one place is.

Now let's get to the nitty gritty. Introductions are frequently the most difficult things for people to write. If you follow the advice here, you will wonder why you ever thought the introduction was difficult to write. The sole purpose of the introduction is to get your reader from a standing start to the part of your introduction that reads, "The contributions of this thesis are..." What is a standing start? I tell my students to write for "a smart computer scientist." This means you can assume that terms such as algorithm, main memory, processor, file system, tree, linked list, database, etc are fair game. However, you should not assume that terms such as inode, B+*link-Tree, the semantics of Haskell, direct storage, a pass-through FUSE file system, etc. are widely understood. It's often useful to pick out a specific individual to whom you are writing. If you are a theory person or a formal languages type, just pin a picture of me up on your computer; that will keep you honest. If you are one of my students, pin up a picture of any of my esteemed colleagues in theory: Salil Vadhan, Michael Rabin, Leslie Valiant, Harry Lewis (I leave out Michael Mitzenmacher, because he dabbles in so many different fields, he may very well be a systems person in disguise). These people are all wicked smart, but probably haven't spent the past decade deep in the bowels of the Linux vnode layer (and yes, vnode is another term I'd recommend avoiding in the introduction).

So, you have a very smart reader and you want to give them just enough background and motivation so that when you drop your contributions statement on them, they think, "Wow, that's cool." instead of, "Why should I care?" or "What on earth does that mean?" or, "Does that even matter?"

True confessions here: I never read the paragraph in most papers that says, "In Section 2, we motivate our study. In section 3, we provide background on existing approaches to our problem. Section 4 presents our approach in detail. Section 5 evaluates our approach and shows you how wonderful it is. Section 6 is the conclusion and it concludes our paper." However, in the thesis, you get to tell your story in short form. The chapter by chapter outline is actually the five-minute synopsis of your thesis. It tells the reader just how you are now going to walk them through your research so that they now understand not only what contributions you made, but how you made them, why you made them that way, and what interesting things you discovered along the way. You have the space -- each chapter gets its own paragraph. Do not cut and paste a paragraph from the introduction of the paper that you already published on the work in chapter N. Weave a description of the work presented in chapter N into your story line.

If you've done this well, you've done your reader an enormous service. If someone were holding your reader's child hostage, willing only to let the child go after the reader summarizes your thesis, the reader of a good introduction is in good shape. S/he can explain what you're doing, why you're doing it, what the big results are, and how you are going to convince the world of these things. There, now wasn't that easy?

So, let's wrap up the introductory chapter: It takes your reader from a standing start to a description of your contributions and then walks the reader through the chapter level outline of your thesis describing how it is that the chapters weave together to demonstrate the contributions that you are claiming.

Next, let's talk about related work. Contrary to popular belief, the purpose of the related work section is not to show that you've read a lot of papers. Instead, I like to think of the related work section as a work of art in which you construct a landscape that has a couple of blank white parts in it, and your research perfectly fills those blank spots. A good related work section walks the reader down a garden path such that at the end of it, the reader is left thinking, "Wow -- how could this problem have remained open so long?" or "It seems that this work is so obviously the right thing to be working on. Why am I not working on it?"

OK, so that's the goal, how do you accomplish it? In most theses, the related work section will break down into a few general areas. Figure out what those areas are. I tend to think both visually and hierarchically, which almost always results in my trying to cast my students' dissertations in terms of some multi-dimensional space. (Yeah, that's how my own thesis worked out, so perhaps it's the only thing I know?) If you can cast your work into some space that lets you place related work at particular points in the space and shows how there are regions in the space that are unexplored, and your work just happens to fall into those regions, then you're all set. If you can't do this, then you need to figure out how to place your work in context. What is the body of work out of which your work grew? What work inspired you? To which work should you be comparing your algorithm, approach, implementation? Once you've answered those questions you should know which work you want to discuss and ideally how to organize it. Then, when discussing the work, don't forget the related part. That is, rather than just say, "Peter, Paul, and Mary show that sorting is best done in linear time." explain how that fact relates to your own work. "While Peter, Paul, and Mary pioneered linear time sorting, we go one step beyond their work and show that in these special cases, sub-linear time is easy to obtain." You want to avoid a reader thinking, "Why did you tell me this?" Your prose needs to make it completely clear why the reader is wading through a discussion of work other than what is in your thesis.

You still may be struggling with related work, because you can't decide if it belongs early in your thesis or closer to the end. The reason you are having this struggle is because there are actually two kinds of related work. There is work that gives the reader sufficient background to understand what you're doing. If you're writing a file system thesis, then perhaps you need to explain to your reader what a vnode layer is or what an inode is. I like to think of this sort of related work as background. Then there is the second kind of related work, which I already discussed -- context setting. If you have a significant amount of background to discuss, then I'm a big fan of having a background chapter towards the beginning of the thesis and a related work section towards the end. The reason I like the context-placing related work at the end is that when you're making subtle (or even not-so-subtle) comparisons between your work and existing work, it's easier for the reader to understand it once s/he knows what you are actually doing.

It's a bit challenging to give detailed advice on the meaty chapters of the thesis, since those will vary tremendously from area to area, so I'll try to focus on a few of the things on which I always seem to comment and that seem to apply to a broad range of dissertations.

If your thesis includes algorithmic descriptions, then you're stuck deciding how to express those. Some people use pseudo code; others use real languages. The problem with pseudo code is that it's not precise; the problem with a real language is that the reader may be unfamiliar with the language's syntax. For example, I ended up reading a thesis that had many code samples in Haskell, a language that I really can't read. So, I asked the student to include a short tutorial. There is no single right answer, but you want your thesis to be approachable for as broad a range of reader as possible -- keep that in mind.

Similarly, if you need to present proofs, you need to use a syntax all your readers will understand. Don't assume that everyone reads every proof syntax the same way; define it. This is perhaps one way in which your thesis is quite different from a paper you submit to a conference that has a significant common vocabulary.

Another way your thesis differs from previous publications is that you have the luxury of space. This means that you should expound on some of the "why" questions that you may not have been able to do in shorter papers. Why is your architecture as it is? What else did you consider? Why did you choose what you did? (A lot of this needs to appear at least briefly in a good paper as well, but you get a lot more space in your thesis to explain these things.)

Similarly, there are no page limits, so you needn't cram all your figures into single column format. Make the diagrams, tables, and graphs nice and big so you can annotate them for easier comprehension, and so that your aging readers don't have to squint too much.

When you present performance results, make sure you explain why the results are what they are. In general, I like presenting performance results according to the following formula, "We ran this experiment and expected to see something, because of some reason. Figure X shows the actual results. As expected, on one part of the graph we observe the results we expected, but surprisingly we see that somewhere else the results are quite different. We ran additional experiments to help us understand these anomalous results and discovered something really interesting." Your most interesting results are often those where your experiment produced unexpected results.

Before wrapping up, let's talk about conclusions. Your final chapter needs to wrap up your thesis, come back to the original statement of contributions and now explain them in a bit more detail, since your reader now has both the context as well as an understanding of how you did something. This is where you can talk about the longterm implications or your results, which will lead gracefully into future work. You needn't only talk about work you could do, but how your thesis suggests work in other areas. I like to recommend that my students read thesis conclusions to look for good research projects. Make yours one I want my students to read.

I'll conclude by stating what should be obvious. Make sure you read your thesis through beginning to end to make sure that you introduce items before you discuss them, that you don't say the same thing four times, that the story line flows. Ideally, when you do that you'll be happy with the result. If you're not, perhaps you want to fix it before handing it over to those evaluating it!

Advising Grad Students

It's that time of the year when I have new first year advisees, concentration advisees, new grad students, old grad students, and junior colleagues. I find myself dispensing lots of advice - some of which will (and should) be ignored; some of which might be handy. Just for fun, I thought I'd try to do a series on the different types of advice I give different people.

Today's installment is about advising grad students. Advising graduate students is really quite unlike anything else you've ever done (except perhaps advising your grown children, but I don't have any of those yet, so I don't know; I can hope that my experience advising grad students will make me a better parent; being a parent certainly makes me a better colleague and advisor).

Anyway, there are a couple of statements that ought to be obvious, but that aren't always spelled out in black and white. First off, grad students are adults (then again, I think undergrads are too). And they don't actually work for you (exception: if they are your teaching fellow for a course, then they actually do work for you and different rules apply in that specific context) . If you're a good advisor, they will work with you and they will align their goals with your goals, but they don't really work for you. They work for themselves (face it -- in the sciences and engineering, the stipend we pay them doesn't come close to a fair wage). Their goal is to acquire a PhD and they've entrusted themselves to your guidance. Yeah, really, I view it as an incredible compliment and a huge responsibility when a student decides to work with me. Given the quality of students who apply here, they have choices to attend many fine institutions and work with many talented faculty. If they choose to work with me, they've placed an enormous amount of trust in me.

I don't get to tell my students what to do. I can suggest they do things, but if I do, I darned well better be prepared to explain why I think they should do it and what's in it for them. If the only answer I have is, "I need you to do this." then I'm better off being honest about this and not suggesting it, but saying, "Hey -- I really need you to do this, do you think you could?" If you have a good relationship with your students, they will do that in a heartbeat. If they won't, then it's time to ask yourself where you've messed up. In general, whenever I'm about to suggest that a student do something, undertake a particular project, write a paper, etc., I like to be prepared to answer the question, "What's in it for me?" I've never actually had a student ask that (mostly because I tell them explicitly), but I think it's important that I understand my own motivations.


Let me tell a story -- as I was approached my tenure review, my group got a paper published in one of the top conferences in our field. This was clearly a group project -- we'd built a large system and this was the first real paper where we told the world exactly what it was and how well it worked. The paper was the result of a lot of hard work of three students and myself. Normally I'd have tried to give the talk presentation to the most senior student or the student who'd carried the lion's share of the work -- neither of those two questions was easily answered, and as I said, "tenure was approaching." I explained to the group that I wanted to give the talk. I was pretty blunt -- I explained that I was fully aware that this was a group project and that I could entrust the talk to any of them, but that I felt I needed to do this. It's easy to say that they had to agree, because I was their advisor and they dare not disagree, but I'm reasonably confident they agreed, precisely because I didn't try to justify my request on any meritorious grounds -- I didn't try to make it sound like I had more of a right to give the talk than they did. In fact, I did quite the contrary, I admitted that all of us had a right to give the talk and made it clear that I was asking their permission. By this time, we had a multi-year trust relationship built up -- they knew that I would always look out for their interests and were happy to do the same for me. Fifteen years later, I still think of these people as my friends. Yes, they are former students, but they are friends and colleagues, and those relationships had already started forming oh so many years ago.

Another job of an advisor is to be an advocate, marketing department, and sometimes "mama bear" for her students. For every student, an advisor must be his/her marketing department -- it's your job to introduce your students to the people in your field, talk up their work, give credit for their work when you give talks about "your group's" work, etc. That is the easy part, but what about when things go wrong? Here's an example that actually happened to an undergrad, but the principle was the same. The undergrad undertook a project with another established person in my field. That person then sort of took the work and claimed it as his/her own. The student was upset.


What did I do? Following the principle of, "Students are adults," I first let the student vent. Next I counseled the student on actions he might take. When those actions didn't help, I finally stepped in. it wasn't pleasant; I was jeopardizing my own relationship with the individual; and it wasn't particularly pretty, but it had to be done. If your students can't count on you to really support them when the going gets rough, what kind of message are you giving them about the relationship? Sure, most of the time, students are fully capable of taking care of themselves (as are we all), but every once in awhile we need to pull in the big guns and know they'll support us. I can still think of people who did that for me when I was a grad student and young faculty member, and I'm still grateful.


Then there are the less obvious questions -- how do you teach someone to conduct research? It took me many years to figure this out, but I believe that apprenticeship is the only way that really works. What this means is that you bring new students in on an existing project and let them watch how it works and contribute in small, well-defined ways. Once they've had that experience, with some assistance, they can identify and tackle a small project of their own design. After that, most of them really begin to soar. Along the way, there are moments to put forth your beliefs about research methodology, what constitutes a good problem, LPU (least publishable units) versus meatier papers, writing, giving talks, etc. However, I firmly believe that the groundwork you lay in those early apprenticeships are critical. The two failure modes I've observed are, 1) assuming that since they've done well in the past they know what they are doing and simply turning them loose and 2) assuming that only you have good ideas and if they aren't working on your ideas, they aren't doing anything valuable. Both approaches can have dire consequences -- I've met highly recommended, very strong PhDs who did not seem capable of identifying a good research problem or setting a research agenda and I've seen really smart gifted graduate students flail, being unsure how to get started.

There are dozens of other parts to advising graduate students, but I'll stop here for now with this: Treat your graduate students as you would have liked to be treated as a graduate student, not necessarily how you were treated as a graduate student.