Studying science is different from doing original science. The skillset for getting good grades in undergraduate math/sciences classes has some overlap with the skillset of proper scientific research, but much lies outside that intersection. This is clear to any science professor or senior researcher who has mentored early graduate students. It’s not uncommon to see someone with mediocre grades be excellent at cutting-edge research, or conversely for someone who got straight A’s to be unproductive in a real laboratory.
This disconnect between curriculum learning and original research is well known in practice, but it should be pointed out more explicitly than it typically is. I think that if more undergrads and early-stage graduate students were explicitly told about the common pitfalls of independent research, they would be much more productive earlier.
Here is a list of pointers for young researchers (undergraduates or first-year grad students) beginning scientific research. Some of these come from reflecting on my own mistakes, and others are based on my observation of other researchers. A couple of these have been on my mind for a while because my undergraduate advisor stressed their importance (#2 and #9). Some are specific to computational and theoretical science, while others should be generally applicable to most academic fields.
You must learn through self-teaching.
You should assume you have to self-teach everything. Of course sometimes your mentors will help you, and you should ask for help when you’re stuck. But you should see it as being a self-taught experience. The acronym ‘RTFM’ exists for a reason, and either way for your career it is vital to be able to work through things it on your own.
Read the literature.
You are expected to have read the research papers that are most relevant to your research project. Your project will lie in a niche of a niche of a niche. You should read the majority of papers that pertain to this triple-niche–don’t worry, there might not be more than 10 of them. And, don’t forget textbooks. They are an amazing human invention–a distillation of decades worth of discoveries condensed into digestible format.
You will be expected to handle obstacles on your own without guidance.
Discovered a bug in your code? Tried and failed to work through a math derivation? You should ask for help if you’ve already seriously tried to work through it on your own–but understand that your mentors’ default attitude is that it’s your job to remove the obstacle. (As your career progresses, this makes complete sense anyway–there is possibly no one in the world who knows your niche-of-a-niche better than you. It would often just take someone else longer than you. However, don’t take this to the extreme—ask small questions when you can—just don’t expect anyone to spend a ton of their time doing something that you could do on your own.)
Write research papers in small pieces.
Many procrastinate writing up their results because it seems like a daunting task, as though you have to sit down for 5 hours and pump out a lot. You will find it less stressful to instead do a little every day. For instance, tell yourself that on Tuesday afternoon you’ll collect the 20 most relevant references in bibtex form, or that you’ll write just 300 words of the introduction. Or, use “the stop watch method,” i.e. tell yourself you’ll write for just 25 minutes per day this week. This strategy makes the task less daunting, and you may finish the full paper more quickly than you otherwise would have.
Assume you will have to re-run your code or related analysis.
This one is specifically for code-based projects: Save all your output, save all your output, save all your output. But also, structure the code in such a way that you can re-run it easily without hassle. You should assume that there will be some kind of modification to the original problem, and that you’ll have to run the full pipeline again at a moment’s notice.
Remember much of the world revolves around resources.
So many of your interactions will implicitly be about obtaining more resources or making good use of resources, even if it isn’t always said out loud. Don’t let this be disillusioning and don’t let it affect your principles, but be clear-eyed about it. Your advisor spent many hours getting funding for your salary or for your equipment, and s/he doesn’t want it to go to waste. Another example: researchers might want to collaborate simply because it helps them get more funding down the line.
Unit testing is a concept in software engineering that ought to be used by more scientists. Some basic rules: (a) keep your tests very very small, hopefully pen-and-paper-provable small, (b) keep your tests separate from your main code, ideally with the aid of a unit testing framework like pytest, (c) write the tests before you write the code! There is much more to unit testing and I suggest taking a brief online course.
Grit grit grit and patience.
This is perhaps one of the bigger differences with undergrad curriculum learning. You think you needed grit for passing your differential equations class? That’s nothing compared to scientific research. This is partly because you are (by definition) exploring the unknown, and as a result you will encounter far more obstacles than you would in a designed-for-students course.
Build your network.
But do it intelligently and subtly. Go to conferences, ask meaningful questions. But try not to be the cringy person who just tries to network with as many high-profile people as possible.
You really can contribute to science. It’s thrilling.
You’ll have that first moment when you realize you know more than anyone else in the room about the topic being discussed. You’ll have that moment when you see that your work is actually useful to other scientists or to the broader world. It’s a wonderful feeling.
Although those who stay in scientific research will learn these principles eventually, an explicit list like this ought to be given to early-stage researchers. The sooner you learn them the more productive and fulfilled you will be as a researcher.