Course Information

Table of Contents

• 1) Course Description
• 2) Schedule
• 3) Staff
• 4) Course Components and Grading
• 4.1) Overall Grade and Grade Components
• 4.2) Laboratory Assignments
• 4.2.1) Grading
• 4.3) Quizzes
• 4.3.1) Grading
• 5) Lateness
• 5.1) Extensions
• 6) Collaboration Policies
• 6.1) Quizzes
• 6.2) Laboratories
• 6.3) Examples
• 6.4) Consequences
• 6.5) Questions

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.

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.

6.009 is required for 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:

  • The Python Tutorial
  • 6.145 Course Notes

• 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

Lectures

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
Srini Devadas	Instructor	32-G844	devadas
Maryam Archie	TA	--	marchie
Heather Berlin	TA	--	hberlin
Jeff Chow	UTA	--	jeffchow
Zachary Collins	UTA	--	zcollins
Alexandra Dima	UTA	--	adadima
Kevin Fang	UTA	--	kevin21
Zachary Holbrook	UTA	--	zackh
Rami Manna	UTA	--	piday
Jisoo Min	TA	--	jisoomin
Cavin Mozarmi	TA	--	cmozarmi
Aron Perez-Lopez	UTA	--	arpl
Olasubomi "Subby" Olubeko	TA	--	subbyo
Valerie Richmond	TA	--	vrichmon
Elijah Rivera	UTA	--	eerivera
Hin Nok "Oscar" Suen	UTA	--	osuen
Kentaro Tanaka	UTA	--	kentnk
Joseph Torres	UTA	--	jmtorres
Yanni Wang	UTA	--	yanniw

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.

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)
            else:
                bounds = (16, 17)
        else:
            # 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 GitHub¹.

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 attribution².

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

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?
-- Yes No

¹People 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)

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