How Assignments work in CS111

Workflow

1. Assignment handouts will be posted on the course website. Homeworks and projects will be posted on Wednesdays and due on Tuesdays.

   • Some needed material may be finished in class on the Friday after the assignment gets posted. Such material will be marked as such in the handout.
   • In general, assume that most questions of the form "how do I do X again?" are answered in the lecture materials from the Friday-Monday-Wednesday before the homework is released. We expect you to try finding these answers in your notes (that's part of learning).

2. Handouts will include a setup section telling you what files to download and what files (and their names) to create.

   • You must use the filenames we provide or the tools that help us with grading won't find your work.

3. Assignments will include an "autograder check block" at the bottom. Copy and paste this into your code file as you are close to finishing. It will check that your code uses the same names and input/output types for functions. This greatly improves the likelihood that your code will run within our grading tools.

4. Assignments may ask you to create multiple files for different activities. These could include programs/code, test cases, program plans, and answers to written or conceptual questions. There will be a summary of the required files at the top and bottom of each handout

5. Assignments get handed in on Gradescope. Depending on the activities on an assignment, we may ask you to submit materials to multiple Gradescope assignments. For example:

   • Programs and plans get submitted to "Assignment Name - Programming"
   • Testing files (may) get submitted to "Assignment Name - Testing" (sometimes they will just be submitted with the programs)
   • Conceptual and written work get "Assignment Name - Written"

We realize that having mutiple submission areas is annoying. We do this because it helps us manage grading within the limitations of Gradescope (which is vastly better than other submission tools we could be using).

Pair Projects

Pair projects span two weeks rather than one (still release Wednesday, due Tuesday). For the two pair projects, the workflow includes two additional steps:

1. In the week BEFORE a project handout is released, the TAs will send out a form to help us match you with a project partner. You can choose your own, or answer a couple of questions (e.g., roughly when in the day do you have time to meet a partner, do you tend to start projects early or late) and we'll pair you with another student appropriately

2. Within a few days of when the project is released, your pair will

   • submit answers to conceptual questions as a first check on your understanding of what the project is asking you to do
   • meet with a TA to review your design for the project. This step is required (and designed to make sure you are on the right track before you spend too much time coding).

You will need to work with different partners on each of the two projects.

Approaching Assignments

Assignments are designed for deeper practice with material that we have covered in lecture (and sometimes in lab). While the assignment problems will often be a bit harder than what we did in class, we will have done all of the PIECES in class. Thus, part of your task on an assignment is to break it down so you can apply those pieces.

We will use two core techniques to understand and break down problems (both will be taught in class and practiced in lecture).

Writing examples first is how you convince yourself (and us!) that you understand what a question is asking. If you understand a problem, you should be able to write some illustrative examples of what information it takes and what it produces, even if you don't know how to write the code itself. Start from examples. Always.

Program planning is how you break problems down in manageable pieces. Sometimes, we will have you develop program plans within a tool; other times, we will let you draw them on paper. Planning is a crucial skill in program development (it saves you work later, and employers value it). If you don't see how to answer a question, write a plan before you start to code.

You can pose questions on EdStem or in office hours. EdStem is good for quick conceptual questions or for explaining what an error message might mean. EdStem is NOT good for helping you find problems in (aka, debug) your code. If you can't figure out why your code isn't working and it seems like a more than minor issue, come to office hours.

Grading

We grade assignments with a mix of automated grading and manual grading. Automated grading means that we run a set of tests that we wrote against your code. This both checks your functionality and helps us narrow in on where your code might not be working properly. Using the autograder frees up more of our time to give you comments and feedback.

On some assignments, we will also grade the thoroughness of your tests (this is also done by automated tools).

Manual grading will look at the structure and design of your code and data organization, as well as how you present your code to human readers (aka, "style"). We'll also be able to look at cases flagged by the autograder to assess the severity of the mistake in your code.

The grading criteria on the syllabus show that getting code through the autograder all the time is neither necessary nor sufficient to pass the course. So if you think you are mostly there on an assignnent and you need to move on to other work, turn in what you have.

Viewing and Interpreting Feedback

We release feedback on the assignments on Gradescope once everyone's work has been marked. Gradescope will show you the rubric we used and how many points we allocated to each item.

Unfortunately, Gradescope also reports a "total score"/overall grade for each assignment (by adding up all of your points). Since we don't grade by an average over each assignment in full, this total number is meaningless (and we wish we could supress it, but we can't). Under our grading system, as described in the syllabus, we look at your grades in themes (functionality, testing, design, etc).

We will issue period reports (via email) that show your progress within the themes. We'll start doing this after homework 3 is graded (before then, there isn't enough data for the reports to make sense).

Regrade Requests

If you think we misgraded part of an assignment, you can request a regrade within Gradescope. That automatically notifies the staff (though we might not get to respond immediately given how we schedule TA working periods). The regrade option will be open for submissions for one week after we release feedback. You can always check the status of your regrade requests (and our responses) by going to the corresponding assignment in Gradescope.