I have collected here some useful advice for students (both undergraduate and MSc students) doing their individual project with me as supervisor.
This advice is about practical aspects of project work, and especially my preferred methods for ensuring effective interaction between students and supervisor.
It must be used in addition to the rules and recommendations set in the appropriate project scheme document for your course. Please READ them and refer to them when you need to. Knowing rules and deadlines is your responsibility.
It is best to Email from your official University account rather than other accounts: I set up filters to alert me to messages from students, which rely on the standard headers of student accounts. It is also less likely that a spam filter deletes your message.
Since I receive many (60-100) messages per day, it may happen that I miss one: if you don't receive a reply within 2 days, it is not rude (it is actually helpful) to re-send the message ("did you receive this?") and/or call my telephone to inquire. You can also come to my advertised office hours, of course.
Knocking on my door, at other times without prior appointment is not good practice: you will probably find that I cannot interrupt other work to see you, and thus it will be a waste of time for both.
Do not trust the voicemail system: it does not always keep messages.
We will need meetings, more frequently at the start and for those projects where I am the client. Make sure that we agree meeting schedules, clearly, in advance. My diary contains many commitments taken months in advance, so it is best to agree in advance periodic meetings throughout the project period, as well as any special meetings (e.g. any long session to analyse requirements); although at times we may need to reschedule an appointment, or have extra meetings.
Whenever you need unplanned meetings, the fastest way in term time may be to use my office hours for the current week; or else you must contact me to find a different time.
At each meeting, you should take notes, and afterwards send me BRIEF minutes as an Email message: a list of main issues reported/discussed, advice received and actions agreed. Summarise what was said, not just what we talked about ("L advised that I read Lyu's book, ch 5", not "we talked about books to read"). Minutes are important as a check against misunderstandings, that often happen, or forgetting.
In any case, it helps if you keep me informed of your progress on a weekly basis, by sending me short updates every Friday. Remember that you need to spend a large part of your time on your project (for undergraduates, about three days per week, on average): these reports help you to track how you are spending your time, and to ensure - with my help as well - that you spend it well. A few lines are enough:
Summary of this week's activities: .....
Progress against plan: [e.g.: "on plan"; "finished X by planned date"; " Z is late by Y days" I have ]
Summary of coming week's activities: ....., [according to plan/ late/early /added to plan ..]
Identified Risks and Issues: [e.g.: delays and how you are going to recover; things that don't work as expected; previously unplanned needs; thus, any changes of plan ]
As you produce material, it is useful to let me see it:
(this applies both to developing software and to any other work) I expect to see you every week, with your notes and sketches of design solutions, at least until the implementation is well under way. Your main risk is NOT that producing what I need may be too difficult, but that you may work very hard to produce what I do not need. Just as we teach, the most expensive mistakes are not made in the detailed implementation; they are made in requirements. I have seen too many students ask just enough questions to decide among their preconceived ideas of what I may need, and then disappear and build the wrong thing. They missed the main lesson about requirements: "you always overestimate your understanding of the user's requirements. Remember that the user knows his business, and you are just beginning to understand it". Validation of requirements continues until the day the product is signed off. Only by looking at details as a project develops can a client and a developer really know that they have mutual understanding.
I expect to receive many documents from you, from early drafts of e.g. requirement specifications, to the draft project report near the end of your work. I may be supervising, depending on the year, some 10 or 20 students at once. These rules will make it easier to deal with all these documents.
I will often give you written feedback on a draft document, electronically or on a printout. Note that I will not try to indicate every possible problem, as though I were marking your draft; instead I will flag examples of each kind of problem or defect: it's up to you to take the advice and apply it throughout your document or your work. This is especially the case with problems of style, lack of clarity, grammar.I often highlight errors of English, out of habit. But this is not my role. You must use good English: it is part of being clear, and communicating clearly is part of professional competence.
If something I said or wrote is not clear, always feel free to ask questions.
Please read these rules in the appropriate guidance document for the project module, and University documents, and make sure they are clear to you before you produce any document. Violating these rules may have a huge cost (up to expulsion without a degree). These rules are basic customs of professional honesty, so if any student I supervise violates them, even through ignorance, I will take it as a very serious matter.
It is your responsibiliy to understand the rules and apply them. If after reading all the rules and instructions, anything is not clear, ASK! I am here to answer questions.
Last, I'll list here some useful pointers that I have found or that you signal to me: