Policies

Course Components

Your evaluated work in this course will include:

Each will be described in more detail below, as well as on the individual assignment pages.

Active Reading

When learning programming, it’s not enough to simply read a textbook. You must be an active reader with hands on keyboards, trying out examples and working through problems as you learn.

In this class, we scaffold this activity through reading journals, implemented as Jupyter notebooks. These allow you to read, take notes, and work through problems, all in one place.

Reading journals are primarily developmental, so they are not evaluated based on the correctness of your solutions. Journals will be assessed using the following rubric:

Reading journals must be submitted by pushing to GitHub before noon on the day of the class in which they are due to be considered for credit. We will review work from journals in the next class, so it is not practical to get behind. You are allowed one “free pass” missed submission with no questions asked.

Mini-Projects

There will be four mini-projects over the course of the semester. The first two will be completed individually, and you may work in teams on the second two. Combined, these four mini-projects will account for 35% of your final grade.

Later in the semester, you will have an opportunity to close the feedback loop by revisiting one of your earlier mini-project assignments. Using what you learned in the intervening time, you will reflect upon, make corrections, and extend your previous work. This revision exercise accounts for 5% of your final grade.

Late Submissions

The late penalty is 20% per day. However, if you find you are struggling to keep up, the worst thing you can do is to suffer in silence. Please come talk to an instructor or a NINJA. Also, see the bottom of this document for the grading rubric. At the end of the semester we will eliminate the largest late penalty that you have incurred on any mini-project (note that this doesn’t apply to things that need to be prepared specifically for a particular class such as project proposals). The one exception to this rule is that if you are 5 days late with an assignment (so you would receive a 0% without late penalty forgiveness), you will still receive a 0% on that assignment.

Example 1: All mini-projects are on time except mini-project 1 which was 2 days late and mini-project 2 which was 3 days late. When we calculate your final grade the fact that you were 3 days late on mini-project 2 will be disregarded.

Example 2: All mini-projects are on time except mini-project 4 which is 7 days late. You will receive a 0% for mini-project 4. You do not benefit from late penalty forgiveness.

Every file you turn in must have a top-level comment identifying you as the author and listing anyone who made a substantial contribution. This comment is your assertion that the mini-project represents your own work.

Project Toolbox

The purpose of the Project Toolbox exercises is to introduce you to a range of skills that we won’t talk about in class, but that will be helpful for you as you work on your Final Project. Examples include building a graphical user interface, networking, and manipulating images.

These exercises will be completed independently at your own pace, and you will be able to select from a range of options to match your interests. They will be assessed on a completion basis.

You will complete at least five Project Toolbox exercises. At least three must be done before Spring Break (due by March 13th), and the remaining exercises can be completed during the first week of the final project (due by March 28th).

Final Project

During the second half of the semester you will work will a small team on a project of your design. At the end of the semester you will present your project to the class and turn in your code and a final report. We will provide details as we go along.

Participation and Professionalism

We will do lots of fun and useful things during class time. You should plan to be there!

As students, you have some responsibility for creating and maintaining a classroom atmosphere that is conducive to everyone’s learning and enjoyment. I hope you will think about how your participation contributes to the learning environment.

Some things you can do to help:

1. Come to class on time! I will do my best to use class time effectively. Late arrivals are disruptive.
2. Come to class prepared. Make sure you have always completed your reading journal.
3. Try not to fall behind. If we are all working on the same stuff at the same time, everything works better.
4. Be active on Piazza discussions, both asking and answering questions.
5. Take care of your brain. Eat well, sleep well, get some exercises. Come to class ready to work.
6. Be professional.
7. Be respectful.
8. Be generous with your ideas and your time. Help each other.
9. Be reflective. Think about what’s working and what’s not, and take responsibility for making the class work for you.
10. Have fun!

Use of Code From External Sources

In general, you are encouraged to search for and use code from external resources, with appropriate attribution. Guidelines for using external code depend on the context and your use of the code.

For example, if you find snippets of code that make up a small part of an assignment, and assemble them into a solution, that’s perfectly fine. If the snippets demonstrate common use of Python features, you can use them without attribution. Something more substantial or unusual should be attributed.

The goal of the mini-projects is to give you an opportunity to develop programming skills, so you should avoid using online solutions that undermine that goal.

One goal of the reading journals is to evaluate your progress, so you should not use external resources in a way that undermines that goal.

All material that you turn in, is presumed to be your own work, unless you explicitly attribute it to another source. Representing someone else’s work as your own is a violation of engineering ethics and Olin’s Honor Code.

Every code example you turn in must have a top-level comment identifying you as the author and listing anyone who made a substantial contribution. This comment is your assertion that the code represents your own work.

General Grading Rubric

5:

• Functionality: For assignments that have well-specified behavior, the code should be able to pass (or very nearly pass, e.g. there may be minor output formatting issues) automated unit testing of all required features. For open-ended assignments the code must be easy to run without modification and implement all of the required functionality.

• Documentation: all functions are commented with appropriate doc strings. For open-ended assignments there is a README file discussing how to run the program and what it is supposed to do.

• Style: the program exhibits effective modular design. The code does not have unnecessary cut and paste code or magic numbers. Variable and function names are sensibly chosen.

4:

• Functionality: For assignments that have well-specified behavior, the code should implement all of the required functionality. For this grade, it is possible that 10-20% of the functionality may be broken. For open-ended assignments it will be possible to get the code running with modest effort (i.e. it will not be as well documented as in a 5, but it isn’t too hard to intuit how the code works). For these types of assignments all required features must be present, however, some (10-20%) may not be functioning properly or otherwise poorly implemented.

• Documentation: some functions are missing doc strings. Comments are fairly minimal.

• Style: some aspects of the design of the program could be improved to reduce cut and paste code. Variable and function names are for the most part well-chosen.

3:

• Functionality: The code should implement almost all of the required features (it is okay if roughly 20% are not implemented). A significant portion, 30-50%, of the code may not work as it is supposed to.

• Documentation: Docstrings are mostly absent. For well-defined assignments the code does not run as it should based on the assignment spec. For open-ended assignments there may not be any indication of how to run the program, and it is not easy for a NINJA to figure out how the code works (a good test is if you have to e-mail someone to ask them how their code runs, they are probably at this level).

• Style: the program design needs improvement. The code would be a lot cleaner if the author had done a better job thinking through the appropriate functional decomposition. The code has lots of cut and paste and magic numbers. Variable and function names are hard to interpret.

2:

• Functionality: the assignment is incomplete (~50% of the functionality is not implemented). The functionality that is implemented is not 100% correct.

• Documentation: documentation mostly absent.

• Style: design is poor. Very little attention has been paid to choosing a sensible functional decomposition. Variable and function names are chosen almost arbitrarily.

1:

• Functionality: only minimal functionality is present.

• Documentation: little or no documentation.

• Style: no comments or docstrings. Code is not “readable”. Poor choice of variable and function names.

0: they have not turned anything in.

Each assignment should be graded on each of these 3 axes. The final assignment grade will be based on a weighted average of each of these 3 grades with weights as follows: functionality 60%, documentation 20%, style 20%.