General Information & FAQ

The prime objective of 6.102 is learning how to write code that is:

• safe from bugs (SFB),
• easy to understand (ETU), and
• ready for change (RFC).

Every idea and skill in the course is calibrated against those goals. Specific objectives include:

• an understanding of key software engineering ideas, including interfaces, representation independence, specifications, invariants, abstract data types, design patterns, and unit testing

• the ability to apply these ideas to design, implement, and test a small- to medium-scale software system (up to a few thousand lines of code, multiple modules), by:

  • defining abstract data types
  • writing specifications for operations
  • choosing concrete representations and defining abstraction functions and representation invariants
  • writing a comprehensive suite of unit tests
  • creating regular expressions and grammars for parsing input
  • creating client-server programs that adhere to a given protocol
  • designing a concurrent program using concurrent language features and library types
     

• an understanding of general programming-language concepts such as static typing, exceptions, access control, interfaces, and equality, and ability to use TypeScript as a particular example language with those concepts

• the ability to use modern programming tools (e.g. VS Code, Git) and modern programming technologies (e.g. I/O, regular expressions, network sockets, threads, GUIs)

• experience working in a project team

Class meetings. There are two 90-minute class meetings each week on Tuesday and Thursday. You are expected to attend class and to participate actively in exercises and discussions. The course calendar shows all the dates of the class meetings.

Laptops required. Classes will include programming exercises that require a laptop set up with the course tools. If you don’t have your own laptop and you need to borrow one, IS&T has a short-term laptop loaner program that will lend you one. Alternatively, EECS has a loaner program (with very limited computers) that can be extended throughout a semester. Email Dr. Amanda Beyer-Purvis for more information.

Readings. Most classes will have a reading that you must read, with online exercises that you should do. Readings and exercises are generally due by 10pm the night before class. The online exercises are designed to be feedback about your understanding and practice for the in-class nanoquizzes. They are graded based on effort, not correctness. These readings constitute the course textbook; there is no textbook to buy.

Nanoquizzes. Every class meeting will begin with a short quiz on the required reading for the class, plus recent class meetings. Nanoquizzes are closed-book and closed-notes, with a 3-minute time limit. The nanoquiz is part of the grade for each class, along with in-class programming exercises, clicker questions, and other activities.

In-class exercises. Classtime will include programming exercises, done in pairs. You must collaborate using Constellation to receive credit for programming exercises. If you encounter technical issues, ask a TA for help. If necessary, visit lab hours or post on Piazza to resolve the issue for next time. You are not expected to complete unfinished exercises after class, but TAs and LAs will be happy to help you review or finish them.

Classwork grading. Each class meeting has a classwork grade out of 10 points, which combines exercises before class (such as reading questions), a nanoquiz at the start of class, and exercises during class. Nanoquizzes are graded like quizzes. The nanoquiz is normally worth roughly from 1/3 to 2/3 of the classwork grade, but sometimes less than 1/3. The exact weight will vary from class to class, depending on the number and kind of other activities. Before-class work is graded based on putting effort into it, not whether the answers are correct. In-class work is graded based on whether you put effort into the exercise and make sufficient progress, even if you don’t complete it.

All classwork results are found on Omnivore (see link on the course homepage). This includes both before-class work (reading exercises, Praxis Tutor, GitStream) and in-class work (nanoquizzes, clicker questions, in-class programming). Some results need more time than others to reach Omnivore, so if you don’t see something immediately, please be patient.

Automatic makeups. The lowest 3 classwork grades are automatically dropped, so you are automatically excused from up to three classes.

In addition, the lower bound for your classwork grade for each class is your grade on the next quiz covering that material (scaled to 10 points). Classes 1-10 are covered by Quiz 1, and classes 11-19 are covered by Quiz 2. If you miss a class, or get a low classwork grade for some reason, your classwork grade for that class will never be lower than the corresponding quiz score (scaled to 10 points).

This means that you will automatically make up any missed or low classwork grade when you take the corresponding quiz. Your grade on the quiz (scaled to 10 points) becomes your classwork grade for that class. You do not have to tell us which classes you want to make up this way. It happens automatically for every class whose classwork grade ends up being lower than the corresponding quiz’s scaled grade.

Problem sets. To consolidate your understanding of the ideas from class, you will do five problem sets, PS0 to PS4, involving both design and implementation work. Problem sets will be done individually. More info: collaboration on problem sets.

Code review. As part of each problem set, there will be a code-reviewing period when other students and staff will give you feedback about the code you submitted using a web-based system. You will be expected to participate in this process by reviewing some of your classmates’ code. More details about objectives and guidelines for the code reviewing process: code reviewing.

Iteration. Each problem set will have an initial submission (called alpha), a code review period, and then a resubmission (beta). The alpha submission will be graded by staff and code-reviewed by other students. The beta submission is typically due a few weeks after you receive feedback on alpha, and will only be graded by staff. For the beta, you will be expected to iterate on your design and implementation, fix any failed test cases, and revise your code based on grading feedback and code review feedback. The course calendar has the schedule of alpha and beta deadlines for the problem sets.

The beta submission must address all the code reviews received by the alpha submission. More details here: how should I address my code reviews?

Since the beta submission happens after code review for the problem set, it’s understood that you’ve looked at other students’ written solutions and been inspired by other ways to solve the problems. You must be exceedingly scrupulous, therefore, in not using those written solutions during your revision. Both your original code and your revised code must be your own. Looking at other students’ answers to the problem set while you are revising your solution will be considered a violation of the collaboration policy.

Slack days. To give you some flexibility for periods of heavy workload, minor illness, absence from campus, and other unusual circumstances, you may request limited extensions on problem set deadlines, called slack days. Each slack day is a 24-hour extension on the deadline. You have a budget of 10 slack days for the entire semester, which you may apply to any combination of problem sets on the alpha deadline, the beta deadline, or both. You can use at most 2 slack days for a given deadline. After your deadline has passed, whatever has been pushed to your repository on github.mit.edu is what we will use for grading.

You must request your extension before the problem set is due by logging into the Caesar code-reviewing system and clicking on Request Extension. The system keeps track of your slack days and informs you how many you have left.

Slack days are atomic; you can’t chop them up into slack hours or minutes. If you choose to use a slack day because you’re struggling with an assignment, go to bed and sleep, and get help in the morning. Seriously, that’s why the smallest unit is a day.

Slack days apply only to individual problem sets, not to team projects.

If you have used up your slack days or exceeded the 2-day limit for a single deadline, you will need an instructor’s permission and support from an S³ dean for more extension, and your circumstances will have to be extreme to justify the special request.

Project. You will complete a group software development project at the end of the semester in a team of three students. Every team member is required to participate roughly equally in every activity (design, implementation, test, documentation), and we may ask for an accounting of what each team member did. A single grade will be assigned to all members of the team.

Project teams. Before the project, you will be able to request one or two teammates you would like to work with. If you don’t already know other students in 6.102 this semester, we hope that working together on in-class exercises will give you the opportunity to find potential project partners.

Team meetings. During the project, you and your project team will meet with your TA to discuss the work. Your TA will assign a grade based in part on these meetings. Team meetings will be scheduled during class time reserved for this purpose.

Quizzes. There will be two quizzes. Quiz 1 is shown on the course calendar, and Quiz 2 will be held during the final exam period, so its date and time will be shown on the final exam schedule.

Each quiz will be comprehensive, drawing on any topics covered up to that point in the course, so e.g. Quiz 2 may include topics that were already covered on Quiz 1.

Quiz 1 will be 50 minutes long, and Quiz 2 will be 75 minutes long.

This topic has its own page: collaboration and public sharing.

The relative contributions of the various elements to your grade are:

• Problem sets: 50%. PS0 is worth 6%, and PS1-PS4 are each worth 11%.
• Code review: 5%. Judged by regular participation in code review and providing substantive, useful comments.
• Quizzes: 25%. Quiz 1 is worth 10%, and Quiz 2 (scheduled during the final exam period) is worth 15%.
• Project: 10%.
• Classwork: 10%. Determined by grade on nanoquizzes and effort on reading exercises and in-class exercises.

Letter grades are determined at the end of the semester. The default cutoffs are: a final average of 90 and above is an A, 80 and above is a B, 70 and above is a C. These boundaries may be adjusted downwards if necessary because of the difficulty of the assignments or quizzes, but the boundaries will never be adjusted upwards, so a final average of 90 is guaranteed to be an A. The boundary adjustment is done heuristically, and there are no grade quotas, no grade targets, and no centering of the class on a particular grade boundary.

Every student is considered individually in the final grading meeting, judging from their entire performance in the course. A single bad mark in an otherwise consistent record will often be discounted.