Collated by Diana Bental (D.Bental@lancaster.ac.uk) with the help of contributions from many PhD students, past and present.
This document is intended for supervisors of students registered for higher degrees in just about any University department anywhere.
Though the presentation of the document is deliberately light in tone, the contents are based on a collation of feedback from a fairly large number of students currently pursuing their studies for a Ph.D.
This document is extremely close to that published in the AISB Quarterly (No. 80, Summer 1992), the quarterly magazine of the Society for the Study of Artificial Intelligence and the Simulation of Behaviour. It has been slightly edited by Paul Brna.
``All the information here has in fact been contributed by PhD students, past and present. Much of what is written here has been exaggerated for effect, but it is all based on students' real experiences and some of it is no more than a literal description of what has happened to them.'' (page 60, AISBQ No 80, Summer 1992)
Many PhD students have collaborated to provide the insights that are found within. Our thanks go to them, and to those that helped in pulling the contributions together into such a formidable body of knowledge.
Clearly, it is not easy to prevent reasonably intelligent and mildly motivated students (such as ourselves) from producing useful work. Nevertheless, he has developed some excellent techniques for Thesis Prevention which we feel may be of use to others, and which we, Professor Hacker's research students present here for your enlightenment and entertainment. If you, as a supervisor, wish to prevent your students from researching and writing up a thesis, or indeed doing anything useful at all, we hope you will take inspiration from Prof. Hacker's example.
Try to be away when the student arrives. Out of the country is preferable, but in today's economic climate Prof. Hacker acknowledges that it is also acceptable to be merely in another city. In this case, your student cannot try to set up any kind of regular contact with you, and will be forced to become independent of you early on.
Initially, Prof. Hacker attempted to shelve the whole problem of supervisions by simply refusing to see his students at all. He would smile at them on his way out of the tea room, realising that this was as much supervision as any student could expect, especially if he occasionally discussed the weather with them when meeting in the corridor. He was forced to drop this approach when his department laid down some guidelines which insisted that supervisors should actually sit down in the same room as students every few weeks and discuss the students' work. This was only a temporary setback to the intrepid Prof. Hacker, of the sort that spurs a good researcher on to new heights. It was at this point that he made some stunning discoveries about how to use these meetings to achieve depths of demotivation previously beyond human imagining.
Here are some guidelines which, if adhered to strictly for even quite a short time, will convey the desired message to the student: a student's work is unimportant, uninteresting and not worth anybody's time, not even their supervisor's.
Arrive late for all appointments with the student. If you can't manage that, then be occupied in some long and complicated task when the student arrives and be sure to finish the task before turning your attention to the student.
Encourage interruptions. Do not cut callers short with the rude statement that you are in a meeting. Never re-route telephone calls. Ask the secretaries to route all their calls through your office as a return favour for all those times you've re-routed your calls. Encourage your head of department, researchers from overseas and your three-year-old child to call at these times. Make any outgoing calls that you suddenly realise are necessary.
If supervisions are held in your office (and they needn't be) make sure that you have a keyboard handy. This is so that you can, in the middle of any detailed explanations that your student may indulge in, reach for the keyboard and read your mail. Prof. Hacker likes to get his workstation to emit distracting beeps at random intervals.
Cancel meetings frequently on the flimsiest pretexts that you can. Do not ever tell students that the meeting is cancelled, but let them come prepared for a supervision and find the room empty. (If the students have prepared for the supervision, that is 90 per cent of the benefit anyway, so don't feel that you are depriving them.)
Try as far as possible to conduct the supervision of several students simultaneously. The students can talk to each other, thus decreasing your need to contribute. If they are all working on unrelated projects and share no common terminology, their attempts to hold a useful discussion should provide you with much diversion.
Productivity is increased even further if this is done as a lunch-time exercise. After all, you have to eat sometime, and if you can do this and fulfill your obligations to your students at the same time, so much the better.
Prof. Hacker warns that only experienced supervisors should attempt simultaneous supervision of more than two students. Note also that fewer than two is really not cost effective and in this case you should try to turn up as late as possible, grab your lunch and be busy eating for most of the next 15 minutes (which is the recommended duration for such supervisions).
Do not prepare for any supervision. If you have an excellent memory, know all the background to the student's project and see the student often, then this technique will not help you. But if not, then your failure to take note of what the student has been doing and/or your failure to look back over your notes will enable you to start each supervision from scratch, requiring the student to explain and justify every step of background to their work before they can discuss any real problems with you. Do this one well enough and you will never have to discuss any real technical problems with your student.
You will find that you are expected to talk during supervisions. Prof. Hacker prefers to avoid the strain of listening critically to students' ideas, and still more to avoid the strain of thinking up helpful and detailed advice.
Avoid at all times any discussion of practical possibilities. Inspire the student by using supervision meetings to soliloquise on all your vaguest and most esoteric ideas, particularly on philosophical issues. Tell lengthy anecdotes to illustrate a point which the student will have forgotten by the time you finish.
Your students will also expect you to respond to their ideas. Prof. Hacker has demonstrated that three quite different techniques may be expected to produce the same effect.
A good way to prevent your students from doing any useful research is to ensure that they choose the right topic. An ideal topic is one that the student isn't interested in, and that the supervisor knows nothing about. Prof. Hacker is especially pleased with a topic if the department lacks the facilities required to pursue it, and if any results are likely to be inconclusive.
The department accidentally played right into Prof. Hacker's hands when it instigated the requirement that students submit a thesis proposal at the end of their first year. A feebler supervisor would have given in and tried to ensure that students produce a detailed and well thought out proposal by this deadline. Prof. Hacker is made of sterner stuff. By following techniques given in this section and the reading techniques given in the section below throughout his students' first year, Prof. Hacker was able to use this deadline to panic his students into choosing the right sort of topic - for his purposes.
Discourage students from following up their initial interests. Post-graduate work is a chance to explore new areas! Suggest subject areas that they know nothing about, so that they spend a year or two trying to understand an area before they find out that it's not worth the trouble to pursue.
Suggest that the student should apply a promising technique to a useless area, such as applying termination proof theory to Cobol programs.
Suggest that students should research a `related' area to their current research since the two areas share a common word in their titles, even though they are lightyears apart (see the following section on reading). This could set them on the wrong track for years.
Wait a year or two and then find a good reason why it would be pointless for the student to continue their current line of research. Refer them to the paper that reports someone else having done the work they intend to do, or explain that the equipment or facilities that the project depends upon will be unavailable. Remember that just because you know that a research group of thirty staff is working on a topic that your student is investigating alone, or that your equipment bid is unlikely to be funded, you don't have to tell the student immediately. You wouldn't want to discourage them, after all.
Finally, gild the lily. Prof. Hacker is delighted to report that having been initially sceptical about a student's choice of project and having suggested that the student spend several months preparing some alternative proposals, he was able to inform the student that the student's original proposal was indeed the best.
Guidance on reading is vital. Prof. Hacker's aim is to ensure that his students' reading lists increase in length exponentially.
If ever a student raises an interesting point that Prof. Hacker fears might lead to a technical discussion, he exclaims ``Ah yes, you really must read what Whizzbang and Genius have to say about that in their theses at the University of Obscurity, Darkest Peru in about, oh, 1965''. He makes it quite clear that there is no point discussing the topic further until the student has read the vital reference (or better still, five or six of them).
The choice of reference material should be guided by a generate and test procedure. Prof. Hacker generates appropriate reference material by looking for titles that share a common word with the student's topic regardless of context. He filters out inappropriate references by making sure that all the references he gives are very hard to dig out. (Never actually produce one to lend to your students, for students are independent researchers who must not be spoon-fed.) Prof. Hacker prefers to mention theses done in remote corners of the world and of 1960s or 70's vintage.
The consistent application of these guidelines should put the student into a sufficiently desperate state that they will settle on a completely inappropriate topic when they have to write their thesis proposal (as discussed in the previous section).
If your students get this far (and if you follow all our guidelines strictly, we trust that your students will not), you will need to assist your students and ensure that they never finish writing up. Prof. Hacker takes care to identify every concept referred to in his students' work and reminds students that there must be a background chapter on each concept in the thesis, with accompanying related work section. As the size of this grows (we suspect factorially, see our appendix on complexity theory) that is a very off-putting task. If a student actually attempts the task it is guaranteed to produce a nervous breakdown, as each of these background chapters then requires further elaboration in itself, and so on recursively.
Students will expect that you will read technical papers that they have written, however badly worded, boring and pointless they may be. There are two main approaches to preventing students from giving you things to read. Applied with sufficient vigour they may prevent your student from ever writing anything at all.
Prof. Hacker occasionally takes a more subtle approach, in which comments are always written but are content free or (better still) ambiguous, thus leaving the student with the work of incorporating the wrong ideas into their paper.
If Prof. Hacker makes any comments on style or content, e.g. that some sentence should be re-written in a particular way, Prof. Hacker tries to remember to reverse the comments in the next draft. This can be applied ad infinitum, or at least until he forgets to do it.
Prof. Hacker believes that it is an excellent idea for a supervisor to add his or her name to all of a student's published work. This is justified for two reasons. Firstly, you are doing the student a favour because you are a more famous researcher and therefore your name as co-author will mean that the paper is more likely to be accepted. Secondly, you are the student's supervisor and therefore you are naturally the inspiration for everything the student publishes. This will delight the student even further if you have been practising all the other the techniques proposed here, especially those suggested in the section on reading.
All supervisors should encourage their students to make contacts in other institutions and to broaden their range of interests. The ideal way to do this is to ask students to organise a conference or workshop, preferably on a topic unrelated to their thesis work.
We believe that we have gathered together a collection of techniques that will be of widespread use in the slowing down and prevention of the production of theses for Higher Degrees. We have emphasised the many ways in which a supervisor can contribute, and the great variety of approaches to the prevention of theses. Finally, we would like to think that Professor Hacker's supervision techniques were unique to him but we fear that they are not.