Home / Course Information

Course Information

You are not logged in.

If you are a current student, please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.

Table of Contents

1) Course Description§

Introduces fundamental concepts of programming. Designed to develop skills in applying basic methods from programming languages to abstract problems. Topics include programming and Python basics, computational concepts, software engineering, algorithmic techniques, data types, and recursion. Lab component consists of software design and implementation.

Prerequisites

An understanding of programming in Python is a necessary prerequisite to this course. 6.0001 (or 6.0001 Advanced Standing Exam), 6.0002, or 6.145 (formerly known as 6.s080) can serve as the prerequisite.

This prerequisite is strictly enforced. If you have not met the prerequisite for this course, you will not be able to submit assignments.

Course 6 and Institute Requirements

6.009 is a prerequisite for 6.031 and a co-requisite for 6.006.

6.009 is required for 6-3, 6-7, and 11-6 majors. It can be used as a foundation class for 6-2 majors and as an option to satisfy one of the 6-14 degree requirements and one of the requirements of the Minor in Computer Science.

6.009 satisfies the Institute Laboratory requirement.

Textbook

There is no textbook for this class, and we will provide tutorial material as necessary throughout the term.

In addition, the following are books/resources that others have found useful in the past:

  • Python:

  • Debugging:

    • Debug It!, Paul Butcher, The Pragmatic Bookshelf, 2009
    • Debugging, David J. Agans AMACOM, 2002
    • Why Programs Fail (2nd edition), Andreas Zeller, Morgan Kaufmann, 2009

2) Structure and Schedule§

Lectures

Lectures will be prerecorded, and there is no requirement to watch the videos at any particular time. Videos will be posted on the front page of the web site, typically on Sunday afternoons/evenings.

Wednesday Recitations

The staff will conduct one-hour-long recitations on various topics including testing, debugging, and basic programming concepts. You are welcome to attend any section you wish, but we encourage you to attend the same section each week.

  • Section 1: 8am-9am Eastern with Saman
  • Section 2: 9am-10am Eastern with Saman
  • Section 3: 10am-11am Eastern with Duane
  • Section 4: 11am-12pm Eastern with Duane
  • Section 5: 12pm-1pm Eastern with Adam
  • Section 6: 1pm-2pm Eastern with Max
  • Section 7: 2pm-3pm Eastern with Max
  • Section 8: 3pm-4pm Eastern with Jonathan
  • Section 9: 4pm-5pm Eastern with Jonathan
  • Section 10: 5pm-6pm Eastern with Manya
  • Section 11: 6pm-7pm Eastern with Manya

Office Hours

The staff will be available to answer questions, help with debugging, and complete checkoff meetings during the below office hours:

  • Monday Evenings, 7pm-10pm Eastern
  • Tuesday Mornings, 7am-10am Eastern
  • Tuesday Evenings, 7pm-10pm Eastern
  • Wednesday Evenings, 7pm-10pm Eastern
  • Thursday Mornings, 7am-10am Eastern
  • Thursday Evenings, 7pm-10pm Eastern
  • Fridays, 7am-10am, 11am-5pm Eastern
  • Sundays, 7am-10pm Eastern

During these times, you can use the help queue to request assistance / checkoffs via video chat.

3) Staff§

Contact Information

Our preferred method of contact is through the 6.009 Forum, as that helps us keep everything organized in one place. You can use the following links to send a direct message to the staff or instructors only.

We can also be reached via e-mail, at 6.009-staff@mit.edu (instructors and TAs) or 6.009-instructors@mit.edu (just instructors).

Staff Listing

Name Role Email (@mit.edu) Picture
Duane Boning Lecturer boning boning Photo
Adam Hartz Lecturer hz hz Photo
Saman Amarasinghe Instructor samana samana Photo
Manya Ghobadi Instructor ghobadi ghobadi Photo
Max Goldman Instructor maxg maxg Photo
Jonathan Ragan-Kelley Instructor jrk jrk Photo
Lujing Cen TA lujing lujing Photo
Kevin Fang TA kevin21 kevin21 Photo
Marie Feng TA msfeng msfeng Photo
Silvia Knappe TA seknappe seknappe Photo
Brandon Leitch UTA bleitch bleitch Photo
Helen Li TA li_helen li_helen Photo
Áron Ricardo Perez-Lopez TA arpl arpl Photo
Magdalena Price UTA maprice maprice Photo
Belinda Shi TA beeshi beeshi Photo
Eyob Woldeghebriel TA eyobw eyobw Photo
Adela Yang TA adelay adelay Photo
Essie Yu TA syu2 syu2 Photo

4) Course Components and Grading§

Our goal in assigning a final grade for 6.009 is to balance learning opportunities with the need for assessment. Our strategy is to use two quizzes as our primary assessment tools, and to use laboratory exercises primarily as learning opportunities, and as a way for you to gauge your own progress.

4.1) Grading Scale§

Assignments (both quizzes and labs) are graded in a two-stage process: first, each assignment is assigned some raw number of "points," and then these points are converted to a real number in the range [0, 5] representing a grade on a continuous "GPA" scale, as illustrated below:

Note that a C and above (GPA of 2.0 and above) earns a passing grade, for the purposes of the PE/NE grading system.

4.2) Overall Grade and Grade Components§

The overall grade in 6.009 is a weighted average of several grades on the "GPA" scale described above, weighted as follows:

  • Recitation Participation: 5%
  • Labs: 70%
  • Quiz 1: 10%
  • Quiz 2: 15%

This average will be a number in the range [0, 5], which will be converted back into a final letter grade using the same conversion described above (4 and above is an A, 3 and above is a B, etc.).

4.3) Laboratory Assignments§

You will be responsible for several laboratory assignments during the semester. A typical lab will be one week long, but some labs may be broken down into multiple one-week parts. Each assignment consists of some number of conceptual questions, as well as a substantial programming task.

Labs will typically release on Friday mornings. A small piece of each lab may come due before the following week's lecture (Monday morning), and the remainder of the lab will typically come due on the following Friday afternoon. In order to receive any credit for a lab, you must also complete a "checkoff" conversation with a staff member; a lab's checkoff is due the following Wednesday at 10pm Eastern.

For each lab, you will receive a .zip file containing a code skeleton and a test harness. You are welcome to work offline until you are satisfied, and then to submit your code to the website. In some labs, you may be asked to produce test cases of your own in addition to code to satisfy the lab specification, or to produce artifacts other than code.

4.3.1) Grading§

In general, your score on each lab will be based on three pieces:

  1. "Concept questions" answered via the lab's web page.
  2. Performance against the test cases run on the server.
  3. A video-chat "checkoff" conversation with a staff member, designed to assess your understanding of your code. Code clarity and code complexity/reuse will also be evaluated at the checkoff.

Once the checkoff is completed, your score for the lab will be a number of points (out of 4 possible points per lab). You must complete the checkoff in order to receive any credit for a lab. Note also that your checkoff "freezes" your grade -- any change to your submission that improves your grade will require another checkoff. This means that you must submit concept questions before receiving your checkoff.

Your individual lab scores will be averaged together, and this average will be converted to the "GPA" scale using the following cutoffs:

  • 4.0 points: Top A (5 on GPA scale)
  • 3.7 points: A/B cutoff (4 on GPA scale)
  • 3.3 points: B/C cutoff (3 on GPA scale)
  • 3.0 points: C/D cutoff (2 on GPA scale)
  • 2.0 points: D/F cutoff (1 on GPA scale)
  • 0.0 points: Bottom F (0 on GPA scale)

Values in between those endpoints will receive scores in between their associated GPA-scale grades (for example, a raw average of 3.85 will result in a GPA-scale grade of 4.5).

4.4) Quizzes§

We will also have two 2-hour quizzes, held on Thursdays throughout the semester in the evening (Eastern time). We will offer conflict times in order to provide flexibility for students who cannot attend the regular quiz time.

Quizzes will have similar structure to the labs, but they will be smaller in scope and scale. You are not allowed to communicate with anyone else during a quiz. We will provide a method to ask administrative and clarification questions to staff during the quiz, but you should not expect help from staff on solving problems, formulating algorithms, or coding in Python.

4.4.1) Grading§

Your initial grade for the quiz is based on the test cases you pass during the quiz, and your submission will also be graded for partial credit based on demonstrated progress toward a working solution.

In addition, we also offer a quiz resubmission assignment. If you receive less than full credit on a quiz question, the resubmission assignment offers another attempt on the quiz problems.

If you use the resubmission assignment to submit corrected code that passes all tests for the question, as well as an explanation of your original bug or lack of functionality, you can receive back 25% of the missing credit.

After the resubmission process is completed, your total number of points earned will be converted to a grade on the "GPA" scale. Cutoffs for quizzes will be determined by the course staff, with the intention of aligning the assigned grades with MIT's Definitions of Letter Grades.

This scaling is not necessarily linear (i.e., you should not expect that earning 85% of raw points translates to a grade of 0.85 * 5 = 4.25). Rather, the cutoffs, which change from quiz to quiz, are determined by the staff as a collective whole by looking at the quiz submissions anonymously to determine which scores correspond to the various letter-grade definitions.

5) Lateness§

Lab exercises can be submitted late for partial credit. Similarly, checkoffs can be completed late for partial credit. Raw scores are multiplied by a lateness multiplier based on how late an assignment/checkoff was submitted.

Students can submit an assignment multiple times before and after the deadline for the assignment. Work that is submitted after the deadline has an associated lateness penalty. Lateness penalties for code submissions only apply to the additional points that the late submission received (assuming the new submission passes all tests passed by previous submissions), encouraging you to finish up the lab and get more points. Submitting another version of the lab can never decrease your achievable score; we compute for you the optimal-in-hindsight subsequence of monotonically improving submissions that would optimize your overall score and that ends with your latest submission. If you want to consider a different version of your code as the final submission (which will be the one checked off and awarded final points), please resubmit that version (which will not incur a late-code penalty if it matches the test cases from a previous submission). (In case you misplace them, you can access your old submissions on this server.) For checkoffs, lateness penalties apply to the entirety of the checkoff grade, so try to avoid this.

Each day you are late results in a 25% reduction of points earned for the corresponding component of a given assignment. This 25% penalty accrues linearly over a one-hour period immediately after the date/time that component is due, so being one minute late results in a 0.42% penalty but being an hour late has the same penalty as being 23 hours late (to encourage you to sleep in every 24-hour period).

For the questions/code typically due Fridays at 5pm, lateness accrues from 5-6pm every weekday. Lateness does not accrue on Saturdays or Sundays. For checkoffs, lateness always counts down from 10-11pm (instead of 5-6pm).

For example, suppose that an assignment is due on Friday at 5p, and the following submissions are made by a student:

  • Code that passes 13 out of 20 tests Friday at 3p
  • Code that passes 14 out of 20 tests Friday at 5p
  • Code that passes 18 out of 20 tests (including all test cases from the previous submission) Monday at 5p
  • Code that passes 20 out of 20 tests Tuesday at 5p

The student receives 14 points for the second on-time submission. The student receives 0.75 * (18 − 14) = 3 additional points for the third submission that is counted 1 day late, since lateness does not accrue on Saturdays and Sundays. Finally, the student receives 0.5 * 2 = 1 additional point for the fourth submission that is 2 days late. The total points that the student receives on the assignment is 14 + 3 + 1 = 18 points.

A student can get checked off multiple times prior to the deadline for no penalty. For example, a student who is docked code style points can improve their code style and receive a full-credit checkoff prior to the Wednesday 10pm deadline. Checkoffs after Wednesday 10pm will incur a lateness penalty.

5.1) Extensions§

To help you manage your obligations, each student will be given three automatic four (calendar) day extensions. Each of these extensions applies to all portions of a lab assignment (pre-lecture questions, other questions, checkoff). The extensions are automatic: they are granted by an algorithm that is run at the end of the semester. The algorithm applies the extensions to the three labs that minimize your loss of credit due to lateness.

These three extensions are intended to help you manage events both planned and unexpected that we expect will come up over the course of a typical semester for many students. You may use your three automatic extensions for sports, music, interviews, projects, busy weeks, or any other reason. You do not have to ask for the automatic extensions to be applied (and, indeed, the staff prefer to leave these calculations to our course-management software and not receive e-mail about use of automatic extensions).

If you are experiencing serious personal or medical difficulties that prevent you from completing some of the work in 6.009 on-time, please talk with a Dean at Student Support Services. With their support, we can offer additional extensions or alternative arrangements. Without written support from Student Support Services, we cannot offer any exceptions to the rules outlined on this page, and we advise first mentioning your situation to the instructors after you have obtained a note of support from Student Support Services.

Note that, regardless of the rules outlined here, the final deadline for all submissions and checkoffs is the last day of classes in the semester. This final deadline cannot be extended through the mechanisms described above.

6) Collaboration Policies§

In line with MIT's policy on Academic Integrity, here are our expectations regarding collaboration and sharing of work.

The primary goal of all of the course materials is educational (with the exception of the quizzes, which are primarily used for assessment). We ask you to work through these materials primarily on an individual basis because we feel that the experience will cement the basic technical ideas and lead you to think about bigger conceptual issues. It is your responsibility to take advantage of the opportunity to do this; working too closely with others will rob you of the chance to engage deeply with the material and may lead to poorer understanding and, ultimately, worse performance on the quizzes.

We encourage you to build your programming skills by working on the labs primarily on an individual basis, and to seek assistance from the course staff and the course forum when you are stuck or confused. You may also help each other with work in this class, but there are limits to what you can do, to ensure that everybody has a good individual learning experience. The following sections describe those limits.

6.1) Quizzes§

During quizzes, tou are allowed to access online materials, including search engines, forums, and the Python documentation, but we do not expect these resources to be particularly helpful, so it is likely in your interest not to spend too much time searching them, but rather to focus on solving the quiz itself. Additionally, your code submission should not include any code that you did not write yourself, and you should cite any sources you referenced during the quiz. You may include code you previously wrote yourself, without attribution.

You may not discuss the quiz with other students -- even after you complete the quiz and/or complete any resubmission -- until the resubmission process has been completed for all students and final quiz grades have been assigned because many students will still be working on resubmissions or conflict offerings of the quiz.

These same rules apply to the resubmission assignment for each quiz.

6.2) Laboratories§

Labs are intended to be primarily individual efforts. You are encouraged to discuss high-level approaches, style tips, Python features, etc., with staff and with other students, but the work you submit must be your own. When you submit an assignment under your name, you are certifying that the details are entirely your own work and that you played at least a substantial role in the conception stage.

You may not use materials (including code, pseudocode, etc.) produced as course work by other students (from this term or from previous terms), nor may you provide your work for other students to use. This includes sharing of code through public channels such as GitHub1.

It is also not generally acceptable to use material from external sources like StackOverflow. In particular, if an assignment asks you to implement something, you must create your own thing, rather than reusing one from an external source. In the rare case where an assignment explicitly allows referencing code from an outside source, you must provide proper attribution2.

Keep in mind that when work on an individual laboratory or quiz is copied, both the provider and the consumer of copied materials are violating academic honesty standards, as described above.

A decent rule of thumb that you can usually use as a self-check is that if two people could reasonably hear the same conversation and produce exactly the same code as a result, you are probably talking about the problem in too much detail.

Here is a concise restatement of our overarching collaboration policy for labs: communication with others (beside the 6.009 staff) may not involve code or any other textual form of information that lays out an algorithm (whether written or spoken). E.g., whiteboard diagrams of data structures are OK, collaboratively working out example executions of an algorithm on a whiteboard is OK, but writing "pseudocode" together on a whiteboard and then individually translating it into Python is not OK. Looking at someone else's code while giving help and looking at your own code while giving help both violate the policy. Brainstorming with your fellow students is a great way to help everyone learn, but please keep it to a high conceptual level!

Also, we want to clarify explicitly that these limitations also apply to getting help from students who took the class in prior terms, unless they are members of the current-semester staff. Please ask for permission before any kind of interaction with someone outside our staff where that person will watch you code up a solution, consult their own solution while helping you, or otherwise step outside the bounds allowed by this policy for collaboration between current students.

If you are ever in doubt about what is acceptable, please ask! We want to help you find ways of working in 6.009 that maximize your learning and growth!

6.3) Consequences§

In the interest of fairness to all students, we take these policies seriously. Throughout the semester, we will be running a suite of software to detect violations of these policies.

Violations will result in a grade of zero on the assignment in question. At the discretion of the staff, more severe actions may also be taken (an F in the course overall, reporting to the Office of Student Conduct and Community Standards or the Committee on Discipline, or other actions).


 
Footnotes

1People often want to share their code publicly, e.g., on GitHub, in order to show off a portfolio of code they've written to potential employers. Building a portfolio is a great idea, but 6.009 is not a good class to use for it, because the laboratories and quizzes are fixed by the course staff, not chosen by you. Personal projects, hackathons, and IAP contests are much better ways to build up your portfolio. (click to return to text)

2See this page for more information about how to provide proper attribution. (click to return to text)