Struggling productively in this class

All 400-level CS classes at Colgate University are intended to provide students with a capstone like experience. This means that by the end of this class you are expected to demonstrate the ability to work independently to solve problems and answer questions. This involves finding the balance between struggling productively and asking for help. The following policies are intended to help cultivate this balance through the course. Ultimately, you will face challenging, open-ended questions in your life. This course offers a lower stakes and supportive environment to practice doing this.

Policies

1. I will not answer questions about provided code for the codelet or lab, or help you debug errors from trying to run this code, less than 72 hours before the codelet or lab is due. This means that you should make sure to understand all of the provided code, and how it interacts with the tasks for the codelet or lab before you try to fully tackle any specific part.

2. Starting in Week 3, I will not answer any questions related to package issues, installing environments, or other basic aspects of running code. Talk to your peers, post on discord, or go to the TA open hours.

3. In asking code questions, I will often ask what you would like your code to do. Over the course of the semester, you should move towards asking questions with Minimal reproducible examples. This will help you both refine your question and practice a valuable skill, generating clean, simple, and clear examples.

4. If you ask me a question about some concept you find challenging that’s great. Please leave time for additional questions and work that follows from these questions (i.e., don’t ask it hours before the due date and expect to finish on time).

Things to do when you run into errors or challenges (non-exhaustive)

• Pause, take some time to answer it yourself. Turn to other work and come back and try again. Then ask others.

• Read provided code and documentation

• Did you ask the TA?

• Can you benefit from talking through the concepts with a classmate?

• If you are having issues with installing environments, running files, etc before you reach out to me, pause and ask yourself these questions: Have you had to do something similar in a previous lab or homework? How is what you are doing different from what you’ve done before? Which of these changes are causing the error?

• If something is running for very long, and you are unsure if it should take that long or if your code is incorrect, can you scale down the task and see if it runs more quickly? Note scaling down the task does not always mean changing some number superficially; it will likely require you to read the code you are trying to run, and figure out how the task is implemented or broken down.

• In general it is always good practice to write or test code incrementally: start with a small set of examples and/or try running a few lines of code at a time before scaling up. Similarly, if you are modifying some existing code, change one thing at at time instead of changing everything at once.