A new problem set will go out every Monday, except for the first week of class (because Problem Set 00 had gone out on the previous Tuesday) and the Monday of spring break.
As with all software projects, specifications may change. Significant changes will be announced on Piazza and noted on the web page that describes the problem set. All students are responsible for noting these changes and incorporating them into their solutions. Adapting to changing specifications can be difficult, but it will be easier if you write clear, readable, well-designed programs.
The first five problem sets will be individual assignments, where you are not allowed to discuss your design or code with other students.
For the remaining problem sets, you will work in pairs assigned by the course staff. You will be assigned one partner for three problem sets, and will then be assigned a different partner for the rest of the semester.
For the pair programming assignments, both partners are responsible for understanding all of the code submitted by the team. We strongly recommend (but do not require) you follow the practice known as pair programming.
You are required to commit the current state of your solution to your GitHub repository at the end of every work session. Failure to commit regularly may be regarded as evidence of cheating.
Time on Task
At the end of every work session, before you commit and push a new version of your partial solution to your GitHub repository, you will be required to fill out a form that records the time you spent in that work session.
Problem sets are generally due every Monday at 6pm. (Problem Set 00 is an exception to this rule.)
Shortly after 6pm on the Monday a problem set is due, we will collect your solution as it exists in your GitHub repository. This is an automated process. Extensions are rarely granted, never without very good reason, and should be requested in advance. Forgetting to sync (push) your solution with your GitHub repository is not a good reason for requesting an extension; such requests will be denied. If you sync (push) at the end of every work session, as required, you will not forget to do so before the deadline.
Soon after your submission has been collected from your GitHub repository, it will be tested for correctness. This too is an automated process. At the end of each week a problem set is due, a file containing the results of our automated testing will be added to your GitHub repository.
The results of correctness testing will account for almost one third of your semester grade.
During the week following your submission of a problem set, you will explain your code and its design to course staff and a small audience of other students. These codewalks are designed to simulate the code reviews that have become standard practice in industry, while providing you with constructive feedback from course staff.
The codewalks give you an opportunity to explain and to defend your design and coding practices to course staff. The quality of your presentations will be graded, and those grades will account for almost one fifth of your semester grade.
Based on your presentation and our own examination of your code, the course staff who conduct your codewalk will give you a separate letter grade for your design. Those design grades will account for almost half of your semester grade.
Scheduling of Codewalks
We will ask you to state your preferences for the scheduling of your codewalks, and we will try to honor your preferences, but the number of codewalk slots is just barely large enough to complete all codewalks so your codewalks are unlikely to be scheduled at the times you would most prefer.
Failure to appear at the time of your assigned codewalk is likely to earn you an F for the presentation and design portions of that problem set.
Structure of Codewalks
For problem sets done by individual students, the codewalks will last about 15 minutes. For problem sets done by students working in pairs, the codewalks will last about 30 minutes.
When students are assigned to work in pairs, both students are responsible for the team's entire solution and may be called upon to explain any part of the team's solution.