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) firstname.lastname@example.org 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.
We will use Canvas as our communications channel (announcements and discussion forum) for this class. Please subscribe to notifications or check regularly so you don’t miss any important updates.
Materials used in lectures and the topics discussed each day can be found on this class website, along with the instructions for in-class activities.
In this class, you will learn from (at least) the following activities:
- Pre-class reading preparation
- In-class lectures and activities
- Project Toolboxes
- Final Project
Each of these will be described in more detail below, as well as on the individual assignment pages.
|Participation and Professionalism||5%|
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:
|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|
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. This is because reading journals are preparation for the day’s activity and we will review them 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. If you find yourself falling behind or spending excessive time on reading journals, please reach out to course staff.
There will be four mini-projects over the course of the semester. The first three will be completed individually, and you may work in teams on the fourth. Combined, these four mini-projects will account for 40% of your final grade.
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.
The late penalty for mini-projects and toolboxes 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 single mini-project or toolbox (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 or more 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.
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
As students, you share 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.
The teaching team strives to:
- Be professional and respectful
- Welcome different ways of understanding, knowing and being
- Use class time effectively
- Actively solicit and respond to feedback
- Adhere to our shared agreement around grading
- Trust that you know yourself and your needs, interests, and values better than we do
- Plan fun and useful learning activities during class time.
We ask you to:
- Be professional and respectful
- Come to class on time and prepared (e.g. completed reading journal)
- Be generous with your ideas and your time. Help each other.
- Try not to fall behind. If we are all working on the same stuff at the same time, everything works better. Reach out for help when you need it.
- Be reflective. Think about what’s working and what’s not, and take responsibility for making the class work for you.
- Be active in discussions in class and online, both asking and answering questions. Complete all class surveys on time.
- Take care of your brain. Eat well, sleep well, get some exercises. Come to class ready to work.
- Have fun!
If at any point in the class you find yourself falling behind or struggling, please talk to an instructor or a NINJA. The worst thing you can do is to suffer in silence.
We trust that you are working to the best of your ability and striving to honor your participation pledge. If you struggle, we want to help. There are resources available for all kinds of problems:
- NINJA: For help with content, during scheduled hours or by appointment
- Professors: For help and more detailed explanations during office hours, or office hours by requests
- Your peers: Many students have great success working in a group
- Resources Page: The sidebar has a resources page with many online resources for code help that may save you a trip to a NINJA or be useful tools for your understanding
- Peer Tutors: These are other students who will privately tutor you if you need extra help with course materials. It’s best to ask for a peer tutor right away if you are having problems keeping up while using other resources.
- ARCs: These students are trained to help you not with course material, but with life problems that are standing in the way of your work. They can assist in many ways such as:
- Helping you make a schedule
- Sitting with you while you work as a study buddy
- Support you while you catch up
- Helping you reach out for help
You can get an ARC or a Peer Tutor by contacting a professor or Disability Services.
Much of our focus will be on feedback to help you improve rather than on grades that evaluate your performance. As part of our feedback system, if your performance in the course is not satisfactory, you will hear from your instructors, and we will work with you to develop a plan to help you get back on track. That said, we strongly encourage you to ask for help when you need it rather than waiting for the instructors to approach you with concerns.
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%.
2019 update: Thanks to the Context and Ethics summer team for helpful suggestions to the syllabus