Advising compact

Below I describe some guidelines for students working on advised projects with me (independent studies, senior projects, or master’s theses).¹

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 it.

Requirements

What I expect from students I am advising.

Time

Your most important resource is time. Your thesis or senior project is not like your other classes, which have homeworks or group projects to keep you on track. As deadlines from your classes appear, it will be easy to fall into the trap of under-prioritizing your research project or independent study. 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.²

You should plan to spend 6–8 hours per week on your project. You’re likely enrolled in CSC 4460 Senior Project, or CSC 5591 Research in Computer Science—both 2-unit courses. The conventional expectation is that you devote 3–4 hours per unit per week to any given class. This will naturally ebb and flow, e.g., weeks when you have midterms and projects might be slower, others may see lots of progress.

Each person’s work style will differ, but I also find that it’s better to distribute those 6–8 hours throughout the week, as opposed to working in fewer, longer marathon sessions. This gives you time to step away from your research more frequently, allowing your brain to “work the problem” during the off-time.³

Pre-requisite knowledge/coursework

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 programming ability that is 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 through independent work or by taking graduate-level courses.

Coursework. You can mostly take any courses you want within your degree requirements. But I’ve listed some courses you should prioritize taking, depending on your project.

If your project is related to Computing Education, please prioritize taking

• CSC 3113 Teaching Computing (example offering) or CSC 5113 Computing Education Research and Practice (example offering)
• STAT 3210 Engineering Statistics or STAT 3313 Probability and Random Processes for Engineers, or a grad level STAT course⁴
• You may also want to attend the weekly CS Education Reading Group (email me to be added to the mailing list if interested)

If your project is related to Data Visualization, please prioritize taking

• DATA 3302 Data Visualization (example offering)
• DATA 3301 Introduction to Data Science (required if you’re a data science student, also counts toward the CSC degree)
• CSC 4186 Human-Computer Interaction
• STAT 3210 Engineering Statistics or STAT 3313 Probability and Random Processes for Engineers
• CSC 4037 Web Development

If you can’t take any of the courses above, you can develop those areas of knowledge through independent work. And please note that you’re not expected to go beyond your degree requirements to take them! These are all if-they-fit-into-your-degree-requirements requirements.

Initiative

Remember that these are your projects. Don’t wait for me to tell you what to do next.

I want you to display intellectual independence and initiative as you work on your projects.

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, and doing independent work as needed to develop skills and knowledge that you need to make progress.

Senior projects and independent studies: This means attempting to independently surmount technical issues as they arise.

That said, there is a balance to be struck 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 the day before 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 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 you’d prefer more or less frequent check-ins, we can discuss it.

Seeking help

Don’t hesitate to ask me questions. I can be reached over Slack or email, and I’ll usually respond within a day. This applies to all students that I advise, but particularly to undergraduates. Your research or independent study is a learning experience, and you’re 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 reach out.

Mutual respect

We will foster an environment of mutual 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.

Timeline for MS students

First, please read How long should my senior project or master’s degree take?.

Writing a thesis takes time. It involves multiple rounds of feedback on individual chapters followed by multiple rounds of feedback on the document as a whole. Doing this writing and editing in a rush during the last few weeks will be stressful for us both, because we won’t have the time for this back-and-forth. As far as I know, there is no (good) way shorten that timeline.

So, I typically expect writing to begin in the term before the term in which you aim to defend your thesis. For example, if you’re planning to defend at the end of Spring semester, you should be writing starting in Fall semester. We should be exchanging sections, chapters, and feedback throughout, and I should see the first complete draft by the start of Spring semester (without sections that cannot be completed as yet because the work is ongoing).

Writing and thinking about your work at that early stage will help you sharpen your understanding of what your project is trying to achieve, and will give us plenty of time to iterate. And if we end up publishing a peer-reviewed paper based on your work, the iteration helps ensure that that paper is filled with your words, as opposed to being heavily edited by me after you graduate.

Use of generative AI

This policy will differ from project to project, and I’m not comfortable issuing general guidance for all projects here. We will talk about expectations in this regard as our collaboration starts to take shape.

However, in some areas, my preference is generally applicable and strongly held:

Don’t use generative AI to produce any prose related to your project.

This includes

• Your senior project report or thesis. The purpose of writing these documents is to communicate your knowledge about your topic (in many cases, knowledge gained as a result of your research) to your readers. Offloading this to generative AI will short-circuit the sensemaking, self-changing process you would undergo while writing, while also making your thesis sound like a super-long LinkedIn post.
• Any academic publications resulting from your work. My preferences aside, this is simply not allowed at most venues.
• Academic posters (e.g., presented at the SURP Symposium or the Senior Project Expo).
• Documentation about a tool you built. I know that writing and updating documentation is a never-ending task in open-source software, but in our project contexts, it is your opportunity to demonstrate your understanding of what you built and why.
• Weekly updates or general communication. I want to hear from you.

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, and 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.