Since unwritten rules are not really rules, below I describe some guidelines for students working on advised projects with me. That is, these guidelines apply to students enrolled in independent studies (CSC 200/400), senior project (CSC 491 + 492 or 497 + 498), or MS theses (CSC 500, 596, 597, and 599).
Note: These are NOT guidelines for minimum requirements for a master’s thesis (or a senior project or independent study). Those will be established on an individual basis, depending on factors like the project you’re working on and your prior experience and expertise.1
To get the most out of this document, bookmark it and return to it frequently to evaluate whether you (and I) are meeting the requirements below. If either one of us is falling short, we can discuss steps to remedy this.
Requirements
What I expect from students I am advising.
Time
You most important resource is time. Your thesis or senior project classes are not like your other classes, which have homeworks or group projects to keep you on track. It will be easy to fall into the trap of under-prioritising your research projects once deadlines from your other classes appear during a quarter. Avoid this by setting aside time and committing to making at least a little progress on your project each week. This little progress can go a long way.2
Pre-requisite knowledge
Technical fundamentals. Projects will often involve building software systems of varying degrees of complexity, ranging from data analysis pipelines that only you will use to user-facing web applications. As such, I expect reasonable familiarity with programming, commensurate with where you are in the program. Senior project and graduate students should be fluent in at least two-to-three programming languages (e.g., Python, Java, JavaScript), and willing to learn more if needed. They should also be familiar with modern software engineering tools and techniques—unit testing, CI, version control, etc.
Research methods. Graduate students are encouraged to develop some basic knowledge of statistics as well as a background in human-subjects research methods (e.g., surveys, interviews, content analysis). This can be done either through independent work or by taking graduate-level courses.
Coursework. If you’re working on a project related to computing education, it’s a good idea to take CSC 313 Teaching Computing as soon as possible, or the graduate course CSC 513 Computing Education Research and Practice if it is being offered. Similarly, be on the lookout for graduate courses in Software Engineering (likely taught by faculty other than me). You may also be interested in attending the weekly CS Education Reading Group.
Initiative
I expect you to display intellectual independence and initiative as you work on your research or software projects with me. For graduate students, this includes conducting background research independently by identifying related prior research, thinking deeply about your research project, and approaching it with genuine curiosity. For senior projects and independent studies, this means attempting to independently surmount technical issues as they arise. For all students—remember that these are your projects. Don’t wait for me to tell you what to do next.
That said, there is a balance to be achieved here. Don’t bang your head against a wall in the name of independence—ask for help or advice when you feel you have attempted to surmount a problem to the best of your ability. I am your advisor; I’m happy to advise.
Self-care
Take care of your own physical and mental health. Research projects or independent studies can feel overwhelming because often they are never “finished”. Just like you set aside time each week to make progress on your project, also spend time to take care of yourself. Take time off when needed, and maintain hobbies and personal commitments that are important to you.
If a personal situation arises that you need to deal with (family situation, personal illness, etc.) don’t stress about getting work done. Just drop me a quick note to let me know.
Communication
Communication between you and me will be the most important predictor of a successful collaboration.
Progress updates
I will expect regular updates about project progress. In most cases, this will take place in the form of weekly check-in meetings in which you will discuss the work you have done over the previous week, as well as your plan for the next week.
Send me a message at least two hours prior to our meeting, briefly answering the following:
- What did you do? (Demos would be great! Did you implement new functionality? Demo it. Did you analyse some data? Show a chart.)
- What do you plan to do next?
- What do you want to discuss?
- What resources/help do you need?
This doesn’t have to be a super formal document. It can be a simple Slack message or email. Its main purpose is to set an agenda for our meeting and to help me regain context prior to our meeting.
If you won’t be present at a meeting, it’s doubly important that you send me this update, preferably with a bit more detail. Please do not skip meetings without giving me prior notice unless it’s for an unforeseen circumstance or emergency.
Finally, if after a few weeks of working together, you think that you would prefer more or less frequent check-ins, we can discuss it.
Seeking help
Don’t hesitate to ask me questions. This applies to all students that I advise, but particularly to undergraduates. Your research or independent study is a learning experience, and you are not expected to know everything right off the bat. If you get stuck, by all means try to get un-stuck. But if that doesn’t work, ask me for help!
Please do not struggle until our weekly meeting to do this.
Mutual respect
We will foster an environment of mutual respect—respect for each other as well as for other students in group meetings or otherwise. This includes being generous with your expertise as well as being open to accepting help or advice from each other.
Other good practices
Attention to detail.
- Do not rush. Last-minute engineering work, one-off experiments, and hasty analyses add up to scientific misconduct and sloppy software.
- Keep records of the work that you do. You may need to revisit something you did many weeks or months ago—being unable to explain what you did or why you did it is a big no-no.
Engineering practices.
- Use reasonably modern development practices and environments.
- Write comments explaining the code you write as well as higher-level documentation, particularly if you are building software that future developers might extend (looking at you, MS students).
- Write automated tests for your software. Your software is a research prototype, so it doesn’t need to be bulletproof. But it should be tested enough to be considered trustworthy.