to a beginning doctoral student that they work on the problem. Since you have a path in mind, it is easy to raise questions that will lead them where they should go, until they have worked through to the solution on their own. A single experience like this is usually enough to get them operating independently.
˲ Try getting the student to make an early transition from reading papers to exploring their own ideas. Certainly, you need to read enough to get the concepts of your field, but after a point, the more you read, the closer your mode of thinking becomes to that of the field at large, and “out of the box” thinking becomes harder. If they produce promising ideas, then of course a more careful literature search must be performed. I’ve seen enough examples to believe that it is a rare case (although sadly not impossible) where the student’s ideas are completely subsumed under what has already been done.
˲ My colleague Hector Garcia-Molina often encourages students to start not by looking for the theoretically optimal solution, but for a simple, easily implementable solution that gets you 90% of the way there. The optimality might be studied later and can form an important part of the thesis.
˲My colleague John Mitchell reminds us that even after getting past the hurdle of believing one can invent, the thesis can be intimidating because of its large scale. He gets students to focus on writing a single paper ( preferably for a conference where they will meet people, not for a journal). After they have written a few papers, building a thesis from them will seem much less intimidating.
Expressing ideas. An advisor must make sure that their students can write clearly. There is little point training students to generate great ideas if they cannot communicate them. It is essential that the advisor reads very carefully and checks every sentence of a student’s first attempts at writing. A common situation, and one that must be caught early, is writing that goes into a lot of detail on the easy parts, and gets fuzzy or overly terse when it comes to presenting the hard parts: the proof of a key theorem or the details of a complex algorithm, for example. So an advisor must judge what is hard and
be sure that the writing does justice to
a
those parts.
Fear factor. Yet another common job of the advisor is to teach the student to fail cheerfully and without embarrassment. Not every student has a built-in fear of failure, but many assume it is wrong to attempt something they doubt is possible. Often, the student’s model of a “problem” comes from homework, where the solution is certainly known. They are ashamed to report “I didn’t get anything done this week,” even if it was not for lack of effort. You don’t want students to spend a lot of time trying to write a program that takes another program as input and removes all bugs (as a fellow student of mine was once advised by his advisor to try), but it is OK to encourage a student to do something ambitious and risky, like finding more bugs than anybody else. In these cases, a
a (Aside: While it sounds pedantic at first, you get a huge increase in clarity by chasing the “nonreferential this” from students’ writing. Many students (and others) use “this” to refer to a whole concept rather than a noun. For example: “If you turn the sproggle left, it will jam, and the glorp will not be able to move. This is why we foo the bar.” Now the writer of this prose fully understands about sproggles and glorps, so they know whether we foo the bar because glorps do not move, or because the sproggle jammed. It is important for students to put themselves in the place of their readers, who may be a little shaky on how sproggles and glorps work, and need a more carefully written paragraph. Today, it is not that hard to find a “this” that is nonreferential. Almost all begin sentences, so grepping for ‘This’ will find them.)
vital job of the advisor is getting students to risk their time and effort, and to deal with the case where nothing good results.
Group therapy. A popular technique for encouraging and engaging students is the free lunch. Not only do Ph.D. students benefit, but it can be used to attract undergraduates into the research community. For the past 15 years, I have been privileged to be part of the “Database Group” (now “Infolab”) at Stanford, consisting of faculty Gio Wiederhold, Hector Garcia-Molina, Jennifer Widom, our students, staff, and visitors. At regular Friday lunches, students take turns presenting informal talks on their work, and good-natured argument from the floor is the norm. Students get over the fear of defending their ideas in public, as well as benefiting from insights of others. Students also may practice for an upcoming conference talk and receive very detailed suggestions from fellow students. Another important function of the lunch discussion is bonding, facilitated by a social committee to run group events, and by regular trip reports, which serve as a vehicle for learning about one another’s lives.
It took many years to reach this point, but it is now fairly routine to have substantial software projects carried out in an academic setting. While there will always be the occasional thesis that is purely “pencil-and-paper,” a much more productive approach is to introduce beginning Ph.D. students to a project. Often they enjoy “learning by doing,” contributing to the software development, while learning the new notions that are being investigated by the project. Senior students often get the opportunity to help, and even to supervise, junior students.
The best example I’ve seen of how to use this mode effectively comes from my colleague Jennifer Widom. In a series of innovative projects ( semistruc-tured data, stream databases, and now uncertain databases), she has perfected a routine, consisting of:
1. Define a general goal for the research, and get a team of doctoral students working together.
2. Spend a substantial period of time,
References:
Archives