A new problem set will go out every Monday.
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.
No Pair Programming
All problem sets will be individual assignments, where you are not allowed to discuss your design or code with other students.
Previous editions of this course had students work in pairs for some problem sets. We will NOT be doing this in Fall 2017.
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 must commit a file named yourID-log.txt that records the time you spent in that work session. This form also includes a certification that all the work in your commit is your own.
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.