So we’re going to work together. That’s great! I wrote this thing to help us both get started.
All of the general academic advice I wrote applies, and then there’s this.
At this point I’ve interacted with more students than you have with research supervisors. And I’ve been a student before, but you (I don’t think!) haven’t been a research supervisor before. These give me better odds of knowing what’s going on in your head, research-wise, than you knowing what’s in mine. I’m writing this to give you a better idea of where I’m coming from.
As we work together, I will try hard to understand where you’re coming from, and try to make it clear to you where I’m coming from. We’ll do well together to the extent that we know what one another’s thinking, and that we both expect the same things to happen.
The general rule for our interactions should be the following. If you don’t understand something, think, google, and ask me about it.
When we get to work on some problem, it should be something that makes you excited. If you don’t like a particular research problem, tell me about it. I will do my best to supply enthusiasm, but if you are not enthusiastic about it yourself, I won’t be much help.
My job is to help you become a good researcher. I want you to become independent and go forth and learn and discover and build amazing things (because I want you to teach them to me later!). But in the process, you will get tripped up, make mistakes, get stuck and be generally overwhelmed. After you are a good researcher, you will still get tripped up, make mistakes, get stuck and be generally overwhelmed. But I hope to have prepared you for some of it. It’s not that I’m trying to scare you. It’s that I’ve been there, I understand what you’re going through. Research advising is a mix of idea gardening (“try this, not that”), gym coach (“I’m sure you can push yourself harder than that: don’t hold back”) and support network (“yes, this paper got rejected, but trust me, it’s good work. Let’s keep at it”).
When I started doing research, I had no idea how important perseverance is. Good research is equal amounts intelligence and grit. You already have plenty of the former (you would not be here otherwise), and the good news is that we can train you for the latter. But don’t underestimate the extent to which continued work on a single hard problem can be emotionally draining.
This is why I want to meet with you regularly, why I want to hear from you regularly. I want to know if you’re getting frustrated, and I don’t want you to get burned out. In addition, steady work is better than spiky work. We cannot help that progress is usually spiky, but we can (and should!) have steady effort instead of spiky effort. Deadlines and milestones are beautiful motivators, but they’re also the easiest way to burn out.
When we meet, you should expect a lively discussion. That’s because I want our mistakes and bad ideas to show up sooner rather than later. You should also bring a written document describing what you tried, what worked, and what didn’t, and what’s getting you stuck. Make an effort to write these things down as they are happening, and not an hour before the meeting: the process of writing down is a great way to help your thinking (this has been reinvented many times in the past: you might know it as rubber-duck debugging)
If you’re getting started in research, you will have read more research papers than written them. That might give you the impression the research process is neat and orderly, like the structure of a good paper: we think of a problem, we find related work, come up with a new idea, test it, and then think of what’s next. Well, it’s nothing like that. It’s messy: we know where we want to go, but we do not really know how to get there (that’s the point!). Matt Might has a famous, great illustrated guide to a PhD, which I will only nitpick in one way. Navigating towards boundary feel more like this. It also feels as great as that looks: noticing something no one else has noticed before, in the middle of all this mess, is a huge rush. But as you maybe already know, I (and you, and everyone else, including true geniuses) make a lot of mistakes, and so it’s important to not let the excitement get us ahead of the truth. I want you to become comfortable at staring at ideas (both mine and your own) that you want to be true, and learning to spot the ones that are not1.
In addition, when you are navigating towards the unknown, the unknown is unknown to me too! So, inevitably in the course of your studies, your job will be to teach me, because by definition, no one else will have been where you are. Wild, huh? What this means is that I can teach you how to succesfully “live on the edge”, but you should expect to know things that I don’t, and that you will need to make an effort to explain them to me.
I’m stealing the section title from Philip Guo’s excellent, excellent writeup (I’m not going to hold it against you if you leave now and go read everything Guo has written. Seriously).
It is a bit embarassing that the best way we know how to carry our day-to-day research is by interacting with computers through a command-line interface that’s been the same for, more or less, 40 years. But that’s the world we live in, so my job is to make it as easy as possible for you to get used to it yourself.
You will need to learn git. We are going to use version control to share source code, paper manuscripts, and possibly data. Dropbox is nice, but when the time of a paper deadline arrives, we will want to be editing the same files at the same time. We want to avoid the dreadful “who has the writing token?” emails, and, even more so, we want to avoid the “paper_version1_ab_november_please_stop.tex” madness. Distributed version-control systems are wonderful for that.
You will also need to learn LaTeX. You will be writing a lot, and although there is a lot that’s bad about LaTeX, there’s so much more that’s good.
You will need to learn one of the standard UNIX shells: bash,
tcsh, zsh, or whatever you like. If you use Windows on a
day-to-day basis, I will not be able to help you with your workflow. I
have been bitten by proprietary software way too many times in the
past; even though I run macOS primarily, the stuff I depend on for
research is all open source.
I don’t care what programming language you use for your software, but it will make things much smoother if we speak the same ones. C++, Python, R, and Javascript are what I use on a day-to-day basis (in no particular order), but I speak a little Haskell, Scheme, Julia, OCaml, Java, Rust, and a handful of others. It’s much more important for you to be very proficient with one language than to write in whatever is the new hotness, but if you’re a fan of some particularly cool programming language, tell me about it!
You can use an IDE for developing your code if you like, but if you do
so, I will want you to make sure everything builds from the
command-line (ideally from a single Makefile, but I’ll take ant,
scons, autotools, CMake, or something like that). I’m happy to
share with you whatever little Emacs I’ve picked up over the years,
and if you know vi, I want to learn!
Don’t lose a month of writing because someone stole your laptop, or because some idiot walking past you at the coffee shop decided it was time to plaster your keyboard with caffeine.
Everything that is important about your research should be saved in a system that’s backed up, automatically, by someone other than yourself (emailing files to yourself does not count). Dropbox is not backup. For example, have a cron job that rsyncs your contents with the university machines, or run Arq, or something. I will ask you about your backups.
It’s an integral part of my job to help you succeed. You should ask me about anything you feel comfortable asking. Still, here’s some things to keep in mind.
Good recommendation letters are tremendously important for your success, and I’ll be happy to write them for you. But know that bad recommendation letters hurt more than good recommendation letters help. I can only give you a good recommendation letter if we have worked together in the past. Also, recommendation letters take time to write! Tell me about the letter at least a month in advance, possibly more, ideally more than three months.
Your performance in a course is visible from your transcript, and so a good recommendation letter must include content that is independent of your performance in a course. That means that if you want a good recommendation letter, you should expect to work with me in an independent project (or be willing to work with one of my graduate students in one of their projects). With six months of advance time, we can come up with a plan for the contents of a good letter (which will change depending on your professional goals, and will involve work on your part!). With one month of advance time, it’s often too late.
Take the famous story by Feynman about Wheeler (the paragraph starts with “as a by-product…”). Wheeler suggests to Feynman that the reason all electrons have the same mass is that they are the same electron. This is beautiful, and, that’s why positrons exists: they are just the same electron going back in time. But wait, says Feynman, in that case the direction of time can’t matter, so why do we see more electrons than positrons? Wheeler tries to salvage the idea but no, it doesn’t really work. At the same time, the idea that a positron is indistinguishable to an electron when you flip time does work. Moral: be willing to attack any idea. Good ideas survive, and bad ideas can be turned into good ones. ↩