It was great to mentor students this summer. The pandemic meant that we could only do this remotely1.
Several things I was surprised students may need convincing:
People make mistakes. Just because it is published doesn't mean it is definitively right. While true that it is more likely that we are wrong than that the paper is wrong, we should remain open to the possibility that we are right. We should act as an independent verification.
Students are eager to make progress. However, if you know something went wrong in step one, then why do steps two, three, and four? Go step-by-step and verify each step.
In a similar spirit as the previous point, students hesitate to run at lower resolutions for testing purposes. Surely, higher resolution gives better results? Well, yes, and it will also take a lot longer, making the feedback loop longer. They have problem valuing simpler test cases. In a way the more basic idea here is that as a scientist developing and even using code you need to switch between an engineering mode and a science mode, where when in engineering mode you don't care about how realistic the results are, you only care about their correctness and maybe the performance. Only after switching into science mode, you work to get scientifically useful results.
Students are hesitant to write anything before they know the full answer. OK, I'm not surprised by this. The written word carries some weight with it. However, if you are unsure, just state that in the notes. Writing notes serves as an additional memory space for your thoughts. It also makes discussing equations much easier.
Pushing to git. Git is supposed to facilitate sharing code. However, it seems students prefer to share code in other manners, e.g., Slack. Strange. Or perhaps I misunderstand of how useful git really is.
On second thought, I think git is too complicated for beginners. If you are not already familiar with the problems it solves, then it seems like an unnecessarily powerful tool that makes it too easy to get into hard-to-get-out-of situations.
Levels of understanding. Some students are really good at understanding the details. A big derivation? No problem to follow each and every step of the calculation. But the big picture? Pah! Others only care about the big picture. Details? Pah! Ultimately, both is needed. If you only get the details, at least you can make progress by blindly following the advisor. If you only get the big picture, then you are lost.
Questions. Some professors say there are no stupid questions. Others say there are only stupid questions, so they need to be asked. Either is a way to encourage students to ask whatever is needed to understand. But asking questions is also hard. How to teach to ask questions and feel comfortable doing so? Maybe you just need to be a mentor before you can be a student...
These observations seem to stay true with other students as well. Of course, every student is unique in some way, but all have gone or are going through a rigorous undergrad curriculum, and they are all humans (or so I believe!). So perhaps it is no wonder that there are similarities.
The undergrad curriculum... could it be better? Sometimes I have the feeling that some students expect a problem to be of a given difficulty. That is, when you solve problems in high-school and university, it is often quite clear what level of difficulty and elaboration a problem requires -- how many pages to write, etc. In research, that is not the case. You don't know beforehand if something is trivial, hard, or nigh impossible.
Another idea I heard recently is that in school, students learn to interpolate. In research, however, you need to extrapolate.2
Teach the unkown. I suppose, the challenge of the research advisor is to teach what you don't know. Of course, you have enough background to advise the student, to ask the right questions, to have a good idea where the project is going, etc. But ultimately, the unkown is what is to be taught.