Home / Course Information

Course Information

You are not logged in.

Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.csail.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, construction, and implementation of design.


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.

6.009 is required for the Minor in Computer Science.

6.009 satisfies the Institute Laboratory requirement.


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) Schedule


You are responsible for material presented in lectures, including oral comments made by the lecturer.

  • Mondays, 2:30p - 4:00p (room 32-123)

Wednesday Tutorial/Lab Sessions

The staff will conduct 30-to-60-minute tutorials on various topics including testing, debugging, and basic programming concepts. These tutorials will be held beginning at 10am in 26-100, and 1pm 4-370. Staff will be available throughout the session to answer questions, help with debugging, and complete checkoff meetings, but these will be conducted outside of the presentation of the tutorial to minimize distraction for those who wish to listen to the tutorial.

  • Wednesdays, 9:00a - 11:00a (room 26-100)
  • Wednesdays, 10:00a - 12:00p (room 4-149)
  • Wednesdays, 1:00p - 3:00p (room 4-370)

Friday Lab Sessions

The staff will be available to answer questions, help with debugging, and complete checkoff meetings.

  • Fridays, 9:00a - 11:00a (room 4-370)
  • Fridays, 10:00a - 12:00p (room 3-270)
  • Fridays, 1:00p - 3:00p (room 32-123)

Office Hours

The staff will be available to answer questions, help with debugging, and complete checkoff meetings.

  • Sundays, 1:30p - 10:00p (room 34-303)
  • Mondays, 7:00p - 10:00p (room 34-303)
  • Tuesdays, 7:00p - 10:00p (room 34-303)
  • Wednesdays, 7:00p - 10:00p (rooms 34-302 and 34-303)
  • Thursdays, 7:00p - 10:00p (room 36-153 and 36-155)

3) Staff

Contact Information

  • Instructors: 6.009-instructors@mit.edu
  • TAs: 6.009-tas@mit.edu
  • Individual staff members: see below

Staff Listing

Name Role Office Email (@mit.edu) Picture
Adam Chlipala Instructor 32-G842 adamc Adam
Srini Devadas Instructor 32-G844 devadas Srini
Maryam Archie TA -- marchie Maryam
Heather Berlin TA -- hberlin Heather
Jeff Chow UTA -- jeffchow Jeff
Zachary Collins UTA -- zcollins Zach
Alexandra Dima UTA -- adadima Alexandra
Kevin Fang UTA -- kevin21 Kevin
Zachary Holbrook UTA -- zackh Zack
Rami Manna UTA -- piday Rami
Jisoo Min TA -- jisoomin Jisoo
Cavin Mozarmi TA -- cmozarmi Cavin
Aron Perez-Lopez UTA -- arpl Aron
Olasubomi "Subby" Olubeko TA -- subbyo Subby
Valerie Richmond TA -- vrichmon Valerie
Elijah Rivera UTA -- eerivera Elijah
Hin Nok "Oscar" Suen UTA -- osuen Oscar
Kentaro Tanaka UTA -- kentnk Ken
Joseph Torres UTA -- jmtorres Joseph
Yanni Wang UTA -- yanniw Yanni

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 three 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) Overall Grade and Grade Components

The overall grade in 6.009 is a weighted average as follows:

  • Labs: 40%
  • Quiz 1: 15%
  • Quiz 2: 20%
  • Quiz 3: 25%

Each of the 10 lab assignments is weighed equally (4%).

Letter grades will be assigned from combined scores using the following scale.

GradePoint Range
F< 50

We reserve the right to lower the thresholds during the term and/or at the end of the semester when we assign grades, but we will not raise them. We may also award A+'s above some cutoff in the A range.

4.2) 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 assignment.

Labs will typically release on Friday mornings and come due on the following Friday afternoons. In order to receive any credit for a lab, you must also complete a "checkoff" conversation with a staff member; checkoffs are due the following Wednesdays at 10pm.

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.

4.2.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 face-to-face "checkoff" conversation with a staff member, designed to assess your understanding of your code, as well as code quality and clarity.

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 that a checkoff freezes a grade -- work done after a checkoff will not receive credit, unless it is followed by another checkoff. Therefore, you should complete all work you intend to complete before asking for a checkoff.

4.3) Quizzes

We will also have three 2-hour quizzes, held on Wednesday evenings throughout the semester (see the calendar on the homepage for details).

Quizzes will have similar structure to the labs, but they will be smaller in scope and scale. Proctors will be available to answer administrative questions and clarify specifications, but they should not be relied upon for help solving the problem, formulating an algorithm, or coding in Python.

We expect that you will use your own laptop for the quizzes.

4.3.1) Grading

Your initial grade for the quiz is based on the test cases you pass during the quiz. However, we also offer an optional quiz resubmission process. If you receive less than full credit on a quiz question, you can continue working on the problems and submit corrected code or completely new code that passes all tests for the question, as well as a short explanation of your original bug or lack of functionality. We will then assign partial credit (typically between 25%-75% of the points you originally missed) based on your original quiz submission.

5) Lateness

Lab exercises can be submitted late for partial credit. Raw scores are multiplied by a lateness multiplier based on how late an assignment was submitted. This process is applied separately to the components of a lab (questions/code typically due on Friday and the checkoff conversation due the following Wednesday).

Each day you are late results in a 25% reduction of the maximum score 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. Thus for the questions/code typically due Fridays at 4pm, lateness accrues from 4-5pm every weekday. Lateness does not accrue on Saturdays or Sundays, except in the case when the lab code/questions due date is on a Sunday (in which case lateness accrues over the hour immediately after that due date and time, and then from 4-5pm on weekdays as usual).

The exception to this rule is checkoffs, for which lateness always counts down from 10-11pm (instead of 4-5pm).

Python code for computing lateness is shown below:

from datetime import datetime, timedelta

ONE_DAY = timedelta(days=1)
def lateness(sub, due, checkoff=False):
    Given a submission time and a due time as datetime objects, compute the
    lateness multiplier for an assignment.
    if sub is None:
        return 1.0

    penalty = 0.0 # fractional penalty

    # handle fractional lateness based on the day submitted
    if sub > due:
        weekday = sub.weekday() # Mon = 0, Sun = 6
        if weekday == due.weekday():
            # on the day the assignment is due, count down over 1 hour after
            # the due time
            bounds = (due.hour, due.hour+1)
        elif weekday not in {5, 6}:
            # on other weekdays, penalty accrues 4-5pm for regular assignments,
            # but 10-11pm for checkoffs
            if checkoff:
                bounds = (22, 23)
                bounds = (16, 17)
            # weekends: no penalty (unless assignment was due on weekend)
            bounds = (float('inf'), float('inf'))
        if sub.hour >= bounds[1]:
            # later than the last time, we accrue a whole day of lateness
            penalty += .25
        elif sub.hour >= bounds[0]:
            # between the two times, we accrue a fraction of a day of lateness
            penalty += (sub.minute / 60) * .25

    # compute penalty from whole days late
    due_weekday = due.weekday()
    while sub > due and sub.day != due.day:
        sub -= ONE_DAY
        weekday = sub.weekday() # M = 0, U = 6
        if weekday == due_weekday or weekday not in {5, 6}:
            # penalties accrue on weekdays only, except for assignments due on
            # weekends
            penalty += .25

    return min(1, max(0, 1 - penalty))

5.1) Extensions

To help you manage your obligations, each student will be given four (increased from three) automatic extensions of four (calendar) days each. Each of these extensions applies to all portions of a lab assignment (including 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 four distinct labs that minimize your loss of credit due to lateness.

You may use your automatic extensions for sports, music, interviews, projects, or any other reason. You do not have to ask for the automatic extensions to be applied.

While lateness does not count weekend days, extensions do count weekend days. Therefore, using a four-day extension for a lab that is due Friday at 4pm means that the lab needs to be submitted by the following Tuesday at 4pm.

If you are experiencing 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.

Note that, regardless of the rules outlined here, the final deadline for all submissions and checkoffs is the end of the last class period of 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 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 Piazza page when you are stuck or confused. TAs and LAs will not debug your code remotely so please do not post your code or a pointer to your code and ask the course staff to find bugs in your code. You will have to come to office hours to receive debugging help. 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. This section describes those limits.

6.1) Quizzes

Quizzes in 6.009 are closed-book and closed-Internet -- you are only allowed to access the quiz page on the 6.009 website and the material provided in the .zip file. You are not allowed to access other information on your laptop or on the web. Cell phones and headphones may not be used during the quizzes.

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.

The resubmission process is an optional extension of the quiz, so the quiz rules apply: closed book, closed Internet, no help from staff or other students, no searching online, no accessing other course materials.

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 X," you must create your own X, not reuse one from an external source. In the 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.

6.3) Examples

Alyssa and Ben sit next to each other with their laptops while working on a laboratory. They talk in general terms about different approaches to doing the laboratory. They draw diagrams on the whiteboard. When Alyssa discovers a useful function in the Python library, she mentions it to Ben.


As they type lines of code, they discuss their code line-by-line to make sure both people have the right code.


In a tricky part of the laboratory, Alyssa and Ben look at each other's screens and compare them so that they can get their code right.


Alyssa and Ben have heard about the idea of pseudocode, very high-level but informal programs that coders use to sketch out ideas before implementing. They work together to write pretty complete pseudocode for a lab. They translate it individually into Python code that they can hand in.


(Please ask our staff for permission before sharing anything textual that explains how to write an assigned program.)
Alyssa is standing on top of a building, shouting down lines of code to Ben in the style of a dramatic poetry reading. Louis happens to be walking by and winds up writing a suspiciously similar program.


(In general, any conversation or other communication violates the policy if someone overhearing would wind up writing basically the same code that is being consulted by the speaker. Just mixing up variable names does not bring a program out of the "basically the same" danger zone!)
Alyssa and Ben haven't been working together on the laboratory so far, but Ben is now struggling with a nasty bug. Alyssa sits next to him, looks at his code, and helps him figure out a reasonable test case to narrow down the possible locations of the bug.


Alyssa opens her own laptop, finds her solution to the laboratory and refers to it while she's helping Ben correct his code.


Bob has access to a "bible" of 6.009 answers from previous terms, which he consults when he gets stuck.


Bob makes his code available to his living group, so that others can use it as a reference if they get stuck.


Louis had three laboratories and two quizzes this week, was away from campus for several days for a track meet, and then got sick. He's already budgeted his automatic extensions elsewhere, and he has made almost no progress on the laboratory. Ben feels sorry for Louis and wants to help, so he sits down with Louis and helps him with the laboratory while Louis is working on it. Ben already handed in his own solution, but he doesn't open his own laptop to look at it while he's helping Louis.


Ben opens his laptop and references his own code while he's helping Louis.


Ben has by now spent a couple hours with Louis, and Louis still needs help, but Ben really needs to get back to his own work. He makes his code available to Louis, after Louis promises only to look at it when he really has to.


John and Ellen both worked on their laboratories separately. They exchange their code with each other to check their work.


John and Ellen both worked on their laboratories separately. They exchange their test cases with each other to check their work.


Test cases are part of the material for the laboratory, and part of the learning experience of the course. You are copying if you use somebody else's test cases, even if temporarily.

6.4) 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 Committee on Discipline, or other actions).

6.5) Questions

These policies are put in place with the primary goal of helping everyone learn more effectively. If you have any questions about why the policies are structured as they are, or if a certain type of collaboration is allowed, just ask! You can do so by posting a private question on the Piazza forum, or by sending e-mail to the instructors (6.009-instructors@mit.edu).

Have you read and understood the policies outlined above?


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)