Thursday, April 6, 2017

Do you help your students debug codes?

Faculty vary greatly in their level of involvement with the details of the research projects of the undergrads, Ph.D students, and postdocs they supervise. Here are three different examples based on real senior people.

A. gives the student or postdoc a project topic and basically does not want to talk to them again until they bring a draft of a paper.

B. talks to their students regularly but boasts that they have not looked at a line of computer code since they became a faculty member. It is the sole responsibility of students to write and debug code.

C. is very involved. One night before a conference presentation they stayed up until 3 am trying to debug a students code in the hope of getting some more results to present the next day.

Similar issues arise with analytical calculations or getting experimental apparatus to work.

What is an appropriate level of involvement?
On the one hand, it is important that students take responsibility for their projects and learn to solve their own problems.
On the other hand, faculty can speed things along and sometimes quickly find "bugs" because of experience. Also a more "hands on" approach gives a better feel for how well the student knows what they are doing and is checking things.
It is fascinating and disturbing to me that in the Schon scandal, Batlogg confessed that he never went in the lab and so did not realise there was no real experiment.

I think there is no clear cut answer. Different people have different strengths and interests (both supervisors and students). Some really enjoy the level of detail and others are more interested in the big picture.
However, I must say that I think A. is problematic.
Overall, I am closer to B. than C, but this has varied depending on the person involved, the project, and the technical problems.

What do you think?


  1. Experimental: it varies.
    In the beginning one has to show new students and postdocs around - to show them how things are done (in my field each vacuum system is different). That allows me to get a feel for how they do, see what the reasoning is behind decisions (on operation/measurement details) they make etc.

    Once I'm comfortable with their skills, they do most of it.
    Except when new hardware needs to be made/implemented. Then I'll be there initially to discuss (their!) ideas, then a little later to go over the initial implementation, and finally during the first usage of something new, we do this together.
    The reason is that I need to know how things operate in order to be able to properly oversee what they are doing, help solve (collaborately) potential issues down the line, but most importantly to find the limits of what hardware can do (experimental research often pushes the limits of what a machine was intended to do) - my experience allows for a better assessment of that last point.

    I also every now and then do measurements with them, either for me to learn or to show them details of how to do things they have not encountered before.

    So, in between B and C.

  2. When I started my lab, I knew everything about our primary instrument: how to troubleshoot, how to take it apart and put it back together, do basic repairs/maintenance & etc. I've drifted farther and farther from that level of familiarity the longer I've been a faculty member. In particular, once we upgraded to a newer instrument (a Lexus where our first instrument was more like a Volkswagon Bug) my postdocs and students are much more familiar with the detailed troubleshooting and maintenance than I am. In fact, I think they would greatly prefer that I not touch so I don't mess anything up. We still regularly sit down and look over raw spectra together discussing interpretation and such.

    As far as code, there I'm much more directly involved in writing debugging & etc.

  3. I was ultra a very C-ish experimentalist, as I explicitly went into science to have fun (and got out when it became drudge work spending weeks filling out what were actually lottery forms.)

    I wrote all our code for the experimental apparatus, and did the highest level apparatus design and parts of construction. But once students learned, under my direct gaze, to run it, I could leave them alone, except when one particular laser stopped working.

    I tried very hard to get the students to write as much of the papers as I could.