How to help PhD students when they get blocked (for months) trying to figure out an extremely complicated technical procedure?

Question

My Ph.D. student is stuck on some technicality of their project. It's taken months already, and there is no good progress. The problem lies beyond their project focus and skill set. Thus, even after repeatedly helping the student, the progress remains so slow that we might be unable to finish the remaining project.

I assess that the problem lies in the complexity of the procedure. Lots of small details need to be carefully arranged for it to work. I can do it myself, but it's very hard to explain.

The choice I see is

1. Continue with regular meetings, try to explain as much as possible, and accept that we won't finish the project.
2. Redefine the problem by, e.g., changing assumptions so it becomes more tractable for the student.
3. I solve this part of the problem and then use that knowledge to better nudge the student in the right direction.
4. I solve this part of the problem and hand it to the student so that we can go to the next project phase.

My view on those options are

1. Risky because in my position, I'm too dependent on a project to have good results
2. It Would be the best way in theory, but not feasible in this case.
3. It seems pedagogically ok but possibly still time-consuming.
4. It seems pedagogically problematic as I overwrite months of work.

When I talk with senior colleagues, the conversation is not helpful because they would never touch any practical work themselves anyway. So, they only consider 1. or 2.

What would be your advice in this situation?

Answer 1

You talk about what is "pedagogically ok" vs. "pedagogically problematic."

• If this were an undergraduate teaching situation, I would agree that students need to solve their homework on their own with only nudges from you.
• As I argued here, the same goes for PhD students learning foundational skills (e.g., debugging code).
• But it sounds like this isn't that -- this is an esoteric procedure that is so complicated that even you can barely explain it.

So, I would suggest that you (temporarily) stop thinking of yourself as a teacher and start thinking of yourself as a more senior collaborator. What is the best way for the two of you, as collaborators, to make progress? In other words: if the roles were reversed and your collaborator knew how to do a tricky procedure that you didn't know how to do, what would you prefer?

My guess is that it's mostly #4. Either tell the PhD student exactly how to do it, and why (not just nudges), or do it yourself and then explain it. Either way, the student will know how to do it next time. And you'll be able to move past this difficult, esoteric procedure and onto something more interesting, which is good for both of you.

It seems...problematic as I overwrite months of work.

I would look at this from a different perspective:

• Maybe you misjudged in telling your student to solve this problem on their own. In that case, the sunk cost fallacy applies, and you should cut your losses (and explain this honestly to the student).
• Or maybe you didn't really do anything wrong, and this problem turned out to be more difficult than you expected. That happens all the time in research, and is a good learning opportunity in itself. If you hadn't known how to do this procedure yourself, you might have added a collaborator who does know rather than waste months with both of you stubbornly trying to figure it out.

Answer 2

Similar problems often arise in mathematics and in other fields that need programming. For a mathematician or computer scientist, I would expect the student to works for months on solving technical issues (finding a formal proof, debugging software) but if a physicist or engineer uses mathematics, programming, or any machine to get results for their actual research question, then they should not spend more then a month on the peripheral technical issues. Instead, they should work on their actual question.

So I would start with #3 and switch to #4 when time passes. If possible, #2 might be good, even better if the student proposes the adjusted research question by himself. Often this is not possible due to project scope. #1 offloads the problem to the student, he might not finish his thesis for reasons he is not responsible.

Answer 3

The problem, in my eyes, is a misunderstanding of what a PhD. thesis is meant to teach and demonstrate.

The successful dissertation, and associated research, cannot always discover or build something innovative and profound. There simply aren't enough successes available at any given time to give every competent PhD. student one to write up.

Rather, the purpose of a PhD. thesis is to demonstrate that, if one had discovered something innovative or profound, one is capable of writing it up. Failures will outnumber successes. Can the student write up the failure in such a manner as to be a meaningful resource for future researchers, in steering them away from dead ends. A student who can do that, has properly earned the right to a doctorate degree in their specialty.

The key elements of doing so include, at least:

• Describing the state of the field when the thesis is being written.
• Outlining the research taken, and hypotheses investigated, in a precise and accurate manner while still being sensibly concise and detailed.
• Detailing any perceived reasons for failure; and how subsequent researchers could avoid those hazards.
• Listing possible future directions in which research could be pursued.

In truth, 90% or more of research is comprised of dead ends. Successes are rare. Building a strong brick, in the foundation upon which future researchers will stand, is sufficient to earn the degree.

Nearly any fool can write up a success; the true essence of science is learning both how to write up your failures, and how to not be embarrassed doing so.

Banting and Best didn't win the Nobel Prize for being the first researchers to isolate insulin; their colleague down the hall was. They won the Nobel Prize because they had taken meticulous notes of their failures; and were the first team to both do it a second time and describe to others how it was done.

Answer 4

I am a PhD student myself, but I have some experience supervising master and bachelor theses. To decide the next steps, I would recommend you to split the knowledge required to complete the project into "basic" knowledge and "domain" knowledge.

Basic knowledge are the skills and information anyone would be required to have or know to start the project and show good rate of progress. Because this is your project, you should have all the baseline knowledge, but not all PhD student would have all baseline knowledge.

The domain knowledge is something required to complete the specific task. This knowledge someone learns mostly during the work on the task. Even you may not have all the domain knowledge.

Ideally, you would accept a student who has all or most of the basic knowledge. Then you need to intensively teach only the few missing parts and the student can focus on solving interesting problems in the project.

Important difference between basic and domain knowledge is that teaching basic knowledge saves the students much more time than it costs you to teach. Whereas, with domain knowledge you reach point of diminishing returns in terms of time investment into the project.

Your student seems to be stuck on a "technicality", which you know how to do "quickly". If you classify the missing knowledge as "basic", then you need to bootstrap the student as quickly as possible, so that he or she actually can work in the interesting part of the problem. The reason is that being stuck on a basic problem kills your motivation, and you should try to avoid it.

On the other hand, you stress that the procedure is tricky and seem to struggle with formalizing the process. That is rather characteristic of the domain knowledge. Then you need to decide if you can write some protocol, to make the procedure more reproducible to demote this knowledge to basic knowledge.

If this is domain knowledge that cannot be demoted to basic knowledge by some manual, protocol or a script, then you are in a pickle. The project probably over-promised or you picked a wrong student for the task. If you do heavy-weight teaching, you will waste too much time. If you do the implementation yourself, you will lose time and the student will not learn. If you continue without change, the project and student will probably fail. At this moment you probably need to ask for help, if it is not too late, or reduce the scope of the project to make it manageable. In both cases you probably want to inform somebody who depends on the project results about upcoming delays.

Do not worry about "overwriting months of work", that is sunken cost fallacy. Your goal is to have the project completed on time with good results. The students can learn may more by solving "interesting" problems.