My Advice for Graduate Students

Your mileage may vary.

Becoming a Researcher

  • Ask questions. Now is the time.
  • Take care of yourself. See a doctor regularly.
  • I expect you to perform your work ethically. You can expect the same of me. For details, see the American Physical Society web pages under the headline "Ethics and Values".

  • Always come to my office with something to write on, either a few pieces of paper or a laptop.
  • Make sure you know how to look up articles at arXiv.org, www.inspirehep.net, and adsabs.harvard.edu, given for example, the first author's last name and a year of publication.
  • If you would like to do research with me, be prepared to tell me why.
  • If we haven't seen each other for a few days, when we meet again, you should either have a question to ask or something to present (preferably both). If you haven't made any progress, that's ok, just be prepared to tell me what you tried (even if it didn't work).
  • Sometimes I give you papers to read. When you come back, be prepared to tell me something you learned. You don't have to understand the whole paper, or be able to derive all of the equations, but you should be able to tell me about some detail that you learned (even if it's not a detail that is central to the paper's conclusions).
  • Part of being a graduate student is learning to manage your time. Make sure you're not stagnant and always making progress. Make sure you're never just waiting on me to do something. Efficiency is important. If you're having problems with this, let me know and we'll get it sorted out.
  • Impostor syndrome is real. Everyone feels, at some point, like they're not smart enough. (Me too.) More often than not, you are a lot more capable than you think. In any case, I'm always happy to give you an honest assessment of how I believe you are doing and how you can improve. However, I can tell you the most likely answer already: you are smart enough and yes there are things you can do to improve (and you probably already have a good idea what they are), but I can't make you any guarantees about your future.
  • Go to the department colloquia, the nuclear physics seminars, and the astrophysics seminars. If you're not getting anything out of them, then try to read the relevant papers authored by the presenter the day or night before the seminar.
  • Success in the future requires a solid understanding of the scientific background of your thesis topics and other related topics in the field. I will be able to help you with a small part of this background material, but it is important for you to do a fair amount of reading of papers (and sometimes computer code) on your own. Make sure that reading is an active not passive learning process. For example, try to derive some of the equations in the papers you read, reproduce some of the plots, write some related computer code, or download a related open-source computer code and run it, etc.
  • Plots are the scientific currency which our field uses. You'd be surprised how far you can go with one really great plot. Learn how to make good plots quickly, using whatever software works best for you. I recommend starting with python3 and matplotlib, and I recommend against using Microsoft Excel, but in the end I leave the final answer up to you. I have my own solution for this sort of thing, but it's not well documented yet.

See also "The Worst Advice Grad Students Get", "So you want to be a grad student?", and "Going To An Academic Conference? Here Are Some Tips".

Letter of recommendation?

  • Let me know, preferably a month in advance, that you would like a letter.
  • Send me your CV.
  • Provide for me, as soon as possible, the following information:
    1. the nature of the position you are applying for (postdoc or faculty job?),
    2. the name of your future boss or the head of the search committee,
    3. the institution you are applying to,
    4. the deadline, and
    5. and the way in which the letter is to be sent.
  • Remind me 24-48 hours before the deadline just in case.

Resources for UTK graduate students

My Advice on Talks

First, understand that all of this advice comes from a particular perspective which may not be the same as other faculty.

  • Everyone says this, but it's worth saying again: understand your audience.

  • I'm less picky about looking at the audience versus your slices than I used to be. As you progress in your career, the most important thing here is to communicate that you're excited about the material that you're presenting.

  • Timeliness is important for for graduate students because many of your first talks will be at larger meetings where session chairs are likely to be rather strict. I am of the belief that, if you haven't convinced me of your point in 20 minutes, an extra 2 minutes isn't really going to help your cause. It takes a certain skill to watch the clock and extemporaenously reframe your talk as necessary. In any case, you should always make sure there is some slide in your talk at which you plan to look at the clock and re-evaluate your talk. Then, you can present the following slides faster or slower accordingly. Also, I recommend always having a few extra slides at the end in case you're faster than you expect. Practicing your talk also helps. When I'm practicing, sometimes I like to actually type out what I intend to say. Some other method may work better for you.

  • Be careful about apologizing too much. Act as if you're busy and important and you carefully chose to spend exactly as much time and energy on the presentation as the situation warranted.

  • Be intentional about how you use mathematics, and don't apologize for it. Also, don't skip over mathematics claiming that you did so because it was too difficult. Many people (even those outside academica) do a lot of mathematics, and it's always disappointing to find people giving more weight to the common myth that math is particularly hard, or just too hard for some kinds people, or just too hard for them personally. Math requires practice, just like reading. That's it. Also, when you say you're skipping something because the mathematics is complicated, I typically interpret that as meaning that you didn't feel like taking the time to present the mathematics in a comprehensible manner.

    In my experience, the nuclear physicists and astronomers tend to be completely different about mathematics. Astronomers feel no shame in writing an entire article without a single equation, yet the nuclear physicists don't feel like you've done any real work unless there's a very complicated equation up there some where. [I have received a lot of conflicting advice about this in the past.] Maybe my assessment is completely wrong, but either way you should make sure to understand what is important to your audience and act accordingly.

Computing

  • Steiner's first rule of scientific computing: If at all possible, avoid asking a computer to compute a quantity you don't already understand.
  • Steiner's second rule of scientific computing: Read the first rule again.
  •  
  • Comment your code. Otherwise you'll regret it when you try to come back to it 5 years later. If you don't think you'll come back to it 5 years later, then you're probably writing code to solve the wrong problem.
  • You may spend 10% of your time writing code and 90% of your time debugging it. Obviously, planning ahead is a good idea, but even then, you will spend a lot of time debugging.
  • For debugging, divide and conquer almost always works. Break the problem up into small pieces and test each individual piece and then progressively put them together and test each time you combine the pieces. It's frustrating to me if you come to my office with complaints about debugging when you haven't tried divide and conquer first. Another strategy is to take the function, class, or program which you are attempting to debug, and write it again from scratch (either in the same language or in a different one). It sounds onerous, but it's often faster (especially if you're spending 90% of your time debugging code and 10% of your time writing it)!
  • Make a log somewhere of how you install packages to your computer so that you can fix it when it goes wrong or reproduce it in the future. This is particularly important on Mac laptops, as there is potential confusion between native OSX packages, Fink, MacPorts, homebrew, pip, etc. Not all of these tools play nice with each other.


Back to Andrew W. Steiner at the University of Tennessee.