(I owe this piece to a conversation with Laleh Coté – she’s doing an incredible job on STEM mentorship, and even in these difficult times, she documents her observations on how it impacts these efforts.)I’m always happy to mentor students, for it gives you a change to light a candle, but also forces you to explain things in a legible way – and if you can’t perhaps you don’t really understand things yourself.Berkeley Lab has a great program for interns, and it comes with some resources: WD&E Mentor Handbook (pdf)Because of the pandemic, all the summer internships have morphed into virtual internship. While everyone is still trying to figure out how to make it work best, some initial best practices where collected here: Virtual Remote Mentor Guide -DOE-SC-WDTS Programs- May 2020 (pdf)
Virtual internship: Programming
Since we’re going for virtual internships, odds are that some of the research will include some coding. Here are some resources that were suggeested by other mentors:
- Free C++ tutoroal by John Purcell on Udemy (Suggested by J. De Silva)
- Learning Python on LinkedIn (Suggested bu Deepanwita B.)
- CS61A – Berkeley course
I’m happy to collect additional resources — feel free to send me an email (email@example.com)
Inclusive mentoring practices
If there’s one silver lining of the current situation, it’s that it’s made easier to reach out to places which are further apart, therefore breaking the inherent homogeneity of the community one lives in.A good introduction is the Team up report (pdf) from the American Institute of Physics. Below are the key learning from this report:
Mentor vs. supervisor
One thing that I found a bit perturbing is the lack of distinction between the roles of mentor and supervisor. When you have an intern, you officiate in both roles, but I think it is useful to clarify when the mentorship ends and when the supervision starts. Typically, you want to be a mentor in a more casual setting – not talking about the science you’re doing but inquiring on how your students are doing, providing advice in their curriculum and general guidance on how to conduct research, whereas regular meetings based on the science should come with clear agendas and (ideally) deliverables along a timeline.And here are some random notes to myself on things to teach to students who are interested in science and want to learn how to conduct research:
- First thing on Monday: write down a program for the week. It does not mean that you need to do everything, but these are the things that are in your scope. You’ll see that you often accomplish more things than it seems.
- When you have a meeting, make sure there is an agenda (your supervisor should make one, but if not, make one on your own.) A meeting without an agenda is a rudderless boat.
- Document your thoughts: have a notebook where you write down your thoughts. It’s important to use pen a paper, for thoughts flow more freely (writing is almost meditative), and you keep track of the time
- Organizing your thoughts: document what you do (dump preliminary results in slides)
- Organizing your documents: have a personal master list of all the documents you work on (or sent by your colleagues.) Typically a google doc with links to online documents (put your research on the cloud if you can)
- When you make simulations, always attribute units to your variable. In a computer, a value is abstract, but in a simulation it describes a physical quantity – it’s important to know what you’re talking about. And if you’re not sure, that’s a good occasion.
- It is a sad fact that 95% of young scientists do not pay enough attention to their graph. If you have nice graphs with labels and units, you are already in the first tier!
- Properly label your plots – it will help you later, plus it helps you understand what you’re doing. Make sure your plots have units. You are doing science, not software engineering.
- To learn about something new, do not use google or wikipedia: the information there will be either too vague or too precise. It will be a waste of time, and a waste of your own confidence. Ask people around you for good reference books, or even to explain how it all works
- Learn your tools: how to find papers, how to write and document, how to make a presentation. Ask tips and tricks from your colleague. They may use different tools, and you can pick the ones that work best for you
- This is especially true when learning a new computing language. Get a book or get a course and spend a day or a week if needed. Browsing Google or Stack Overflow will save you time at first, but it is not very useful in the long run.
- In science, it’s ok to say you don’t know. In fact, the more you know, the more you realize how little you know. Be forthcoming when you don’t understand something. And it often takes a few times to fully understand something. If your supervisor is judgemental (she sigh), then the fault is on her, not you.
- It is good to have one or two side projects. They can help refresh your mind, and oftentimes you find unexpected connections with the main project.
- When you’re really stuck, go for a (long) walk (>20min.) Walking is a great way to get new ideas and reflect on something.
- Friday late afternoon: consolidate the knowledge created during the week (group slides by themes)
Before writing a paper (or a note), make sure you can answer these questions
- Background: What issues led to this work? What is the environment that makes this work interesting or important?
- Aim: What did you plan to achieve in this work? What gap is being filled?
- Approach: How did you set about achieving your aims (e.g., experimental method, simulation approach, theoretical approach, combinations of these, etc.)? What did you actually do?
- Results: What were the main results of the study (including numbers, if appropriate)?
- Conclusions: What were your main conclusions? Why are the results important? Where will they lead?