Student Expectations

Ultimate goal

Ultimate goal of the PhD: Become a world-class researcher.

Norm for getting a PhD: Three top-tier, first-author publications.

My evaluation of you is on progress towards the PhD. Top-tier publications are the effect of being a good PhD student, not the cause. Focus on the good behaviors described below, which is how I will evaluate progress towards the goals. There is copious advice from veteran researchers about getting a PhD, which I will link throughout this document.

Being in a PhD program is unlike being an undergraduate. Course grades are necessary, but not sufficient for success. Bad grades matter, because they can preclude passing qualifiers. Good grades are the norm and do little else. Instead, take courses to learn new things that you might apply to your research or for curiosity.

There are lots of traits that make a good researcher. To me, the most important are attitude and motivation. Technical skills can generally be learned. But if you aren't really interested in the day-to-day of academic research, no amount of technical ability will make up for that.

Much has been written on research itself. Here are a couple of examples:

• How to Have a Bad Career by David Patterson.
• "You and Your Research" (Video and Transcript), Richard Hamming. Classic advice on conducting research.
• Technology and Courage by Ivan Sutherland

Ground rules

These are the ground rules for PhD students who work with me. If you can't follow these, you'll PhD career will suffer; it will be hard for me to see your progress; and you will likely not complete the program.

No one likes all of these, but if you hate having to follow most of these, you are probably in the wrong career.

So long, and thanks for the Ph.D.! by Ronald T. Azuma is a very useful, realistic guide to pursuing a PhD.

Be in lab during "normal" business hours.

Don't be a ghost, that student who just happens to be gone for this reason and that whenever I need to get a hold of them.

Good research comes from impromptu discussions that can't be entirely replicated with scheduled virtual meetings. Being around at the same time and in the same place makes this possible. Keep me up-to-date when things change.

Some people might work better at different hours. Once you've shown you can work independently, we can revisit what normal hours are for you, in later years.

Keep a detailed lab notebook.

Don't delude yourself into thinking you can keep it all in your head.

Don't rely on your memory. It isn't reliable.

Instead keep track of everything you do in a lab notebook. Some example include:

• command-line instructions run
• links to repos
• papers read
• insights noticed
• questions asked
• solutions proposed
• todos given to you
• planning
• minutes from meetings
• discussion notes
• talk notes
• and much, much more

Keep track of meetings, todos, etc. Share this lab notebook with me. Use reverse chronological order. You can always create other documents if you want and point to them. Use whatever collaborative platform you like (git, google docs, etc.)

Research work can be very complicated, priorities change, new findings will change plans:

• have a plan
• try it
• adapt and update your plan

You'll get tons of todos. Some will matter more than others. We may not know which until later. Get used to organizing and prioritizing them.

• priority is based on what will lead to novel, publishable scientific results, but this changes as new findings are made
• ask/discuss with me regularly to update priorities and get advice on next steps

Don't be that student who thought they had a great idea or a great solution, only to not be able to remember or replicate it or that takes hours to recreate what they did when they could have just looked at their detailed notes.

You are a computer scientist. Don't try to keep everything in your head. Computers are good at keeping text. If you are smart, you might have gotten away with keeping everything in your head on small course projects, but that approach will quickly break down with the complexity and scale of the work we do.

Prepare for meetings.

Don't be that student who comes to a meeting unprepared. This wastes everyone's time. If you truly have nothing to talk about, then there is likely no need to meet. If you aren't ready, then half of meeting will be wasted on you searching out the info you need to answer questions and discuss your progress.

If you have been maintaining a lab notebook then meeting prep is easy. Go back through your week, summarize, create an agenda, craft questions, etc. Then add that meeting prep to your notebook.

Here are great tips on progress reports and advisor meetings. Use those as a guide.

Being prepared means being a good collaborator. This skill will make you the kind of researcher other people want to work with.

This skill will also help you with teaching and presenting; organization is half the battle.

Do good software engineering.

We do lots of system-esque building in our lab. And we aim for easy replicability, which means having good experiment automation. Both require good software engineering practices.

Being a great software engineer starts with being a great programmer. Here are the three virtues of a great programmer, according to Larry Wall:

1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
3. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

Hacking is okay for prototyping, simple scripts, etc. But once you've got something working, record how you got there and start building the real software.

There's lots of resources on software engineering. But in general you need to

• do planning and design
• use clean and simple architecture
• comment your code (especially before you code)
• document inputs and outputs
• make incremental improvements to software (think minimal viable product)
• write comments and lab notebook records
• use git properly (no -a, no massive commits except perhaps at the very start of a codebase, no lazy commit messages, etc.)
• make code review easy
• test, test, test
• prepare for replicability early, document
  • dependencies
  • platform
  • any other assumptions
  • usage
  • internals
• make software that is easy for others to use

Much of this will come with time, rewriting, rethinking, discussion, etc.

Don't treat your codebase as write-only! If you don't want to look at your own code again, who else would?

Don't keep stuff in your head that's necessary for the code to work as you intended. Use automation and documentation:

• Don't be the student who says "this works, just let me remember how I did it".
• Replicability means someone else can produce your results without having to ask you anything.
• Any steps you do manually should be documented and automated (if reasonable, don't spend hours on something you can just document).

Communicate regularly.

Don't make the mistake of waiting until you are "finished" with something to talk about it. Our work is never finished.

Regular communication prevents going down a rabbit hole for weeks. It means I am kept up-to-date on your status. I forget very fast, especially complex or poorly-thought-through ideas.

Regular communication means you will constantly be reiterating and revising your research story. Take this as an opportunity. You'll have to update me at a high level many times as the picture becomes clearer and couch your detailed technical results in that research context. This is an important skill for creating research projects, writing papers, getting funding, teaching, and much more.

Regular communication shows me you are still there, and I will have a basis to evaluate your progress. Make it easy for me to tell others what a great job you are doing.

Be the tortoise.

Always be working, thinking, improving, documenting, revising, testing, talking, etc.

Don't wait. If you want to procrastinate, do it by working on something else that is productive. Switch between coding, writing, brainstorming, experimenting, etc.

This line of work is hard, complex, and full of pitfalls. You may spend months on a direction that ultimately will not work, so you need to be adaptable. Learn from the experience so that the time is not wasted. Document your work and read other's work, so you don't accidentally repeat history.

Be an active community member.

Come to lab group meetings.

Attend faculty talks, invited talks, etc., given by the department.

Interact with other lab members, department members, community members, etc. Do outreach and volunteering if you have time.

If you think you need to skip an hour-long talk or group meetings because you don't have the time, it's probably because you aren't managing your time properly, not because you really need an extra hour of time doing something like passively listening to a talk, which requires less mental energy than research.

Use good time management.

You have to manage time on your own. This isn't an undergraduate degree where teachers give you detailed syllabi, schedules, problems to work on, etc. You need to be your own instructor.

Don't try to do little for days then binge on work. Few can work for hours and hours straight on complex technical work, writing, brainstorming, problem-solving, etc. And no one can do it all constantly without rest. This is why being the tortoise works. Working in manageable, well-defined chunks of time everyday on one task will likely be more fruitful than trying to get it all done before a progress update meeting. But if you are "in the zone", then by all means keep working.

If you are good at programming, good at writing, etc., and can binge, do it. But check yourself. Are you actually making progress or just thrashing? Do you need a break? If you think you need to keep going to get it done because you have a meeting in an hour, then you probably failed to do proper time management in the first place. If the meeting is a week away and you are on a roll towards some potential result, then by all means take the additional time. There are many different time management strategies. Find what works for you. Ultimately, the ability to follow all of the ground rules above will prove whether your time management is good or not.

There are many, many resources on time management. Here is one: Time Management by Randy Pausch.