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 HW or lab, or help you debug errors from trying to run this code, less than 72 hours before the HW 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 HW or lab before you try to fully tackle any specific part.

2. Starting in Week 6, I will not answer any questions related to package issues, installing environments, or other basic aspects of running modes like interact with NLPScholar. We’ve covered this in lab and homeworks. Talk to your peers, post on discord, or go to the TA open hours.

3. If you have issues, errors, bugs, etc. related to code you should submit your question using formal issues (drawing on standard practice in open source software). If it relates to NLPScholar you should submit an issue on the repo and fill in the Bug/Error template when you do so (it will appear as an option when you go to submit an issue). If it relates to other code, you should use the same basic template. You can find details here. If you do not do this, I will not answer the content of your question.

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?

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