Course Policies

Accessibility Statement

Olin College of Engineering is committed to ensuring the full participation of all students in its programs. If you have a documented disability (or think you may have a disability) and, as a result, need a reasonable accommodation to participate in this class, complete course requirements, or benefit from the College’s programs or services, contact Disability Services at Olin (DSO) disability.services@olin.edu as soon as possible. To receive any academic accommodation, you must be appropriately registered with DSO. The DSO works with students confidentially and does not disclose any disability-related information without their permission. The DSO serves as a clearinghouse on disability issues and works in partnership with faculty and all other student service offices. For further information about services for students with disabilities, please contact the DSO.

Course Components

Your evaluated work in this course will include:

Activity	Approx Weight
Active Reading	10%
Mini-Projects	40%
Project Toolbox	15%
Final Project	30%
Participation and Professionalism	5%

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:

Score	Criterion
2	submitted, all exercises attempted; or, spent allotted time and made use of office hours
1	submitted with serious deficiencies, exercises not attempted or very minimal effort
0	not submitted

You are not expected to spend more than eight hours per week outside of class on all classwork – reading, reading journals, mini-projects, toolboxes, final project. With the exception of the first assignment, you should not spend more time than five hours on a reading journal. You should not spend more than ninety minutes on an assignment without asking an instructor, electronically or by making use of office hours, for help. (Ask for help sooner if you are “stuck”. Banging your head against a wall is not a good use of your time.)

Reading journals must be submitted by pushing to GitHub before 9am on the day of the class in which they are due to be considered for credit. We will review work from journals in class on that day, 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 40% of your final grade.

Late Submissions

The late penalty is 10% 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 10 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 10 days late. You will receive a 0% for mini-project 4. You do not benefit from late penalty forgiveness.

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 four Project Toolbox exercises by the posted deadlines.

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. We hope you will think about how your participation contributes to the learning environment.

Some things you can do to help:

Come to class on time! We will do our best to use class time effectively. Late arrivals are disruptive.
Come to class prepared. Make sure you have always completed your reading journal.
Try not to fall behind. If we are all working on the same stuff at the same time, everything works better.
Be active in discussions in class and online, both asking and answering questions.
Take care of your brain. Eat well, sleep well, get some exercises. Come to class ready to work.
Be professional.
Be respectful.
Be generous with your ideas and your time. Help each other.
Be reflective. Think about what’s working and what’s not, and take responsibility for making the class work for you.
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

This rubric applies to mini-projects and projects. It does not apply to reading journals or toolboxes.

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.

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.

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.

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.

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.

The student did not turn 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%.