CS 61 is a first course in computer systems programming, meaning thecreation of high-performance programs that use computer hardware effectively.Although many programs today are written in high-level programminglanguages—and many programs simply glue together existing components—the bestprogrammers are craftspeople who understand their tools. For softwarebuilders, this requires a working knowledge of computer internal organization.It means understanding how machines interpret instructions, how compilers turnprogramming languages into instructions, and how operating systems combineprograms and libraries to create running code. And it requires understandingthe factors that affect code performance.
CS 61 introduces you the tools you need to build robust, efficient softwareand the mental tools you need to understand software systems written byothers. We hope you’ll discover that systems software development is fun andworth the effort. We intend the course to be broadly accessible, though itwill be easier for those who have some experience with systems programming inC++ or other C-like languages.
Objectives
After this course, you should be able to:
- Write robust and efficient software.
- Use operating system interfaces effectively.
- Read and explain C and C++ programs.
- Read and explain simple assembly programs.
- Write programs that combine C/C++ and assembly language.
- Solve problems using computer arithmetic.
- Solve coding exercises requiring synchronization of concurrent activities.
- Analyze program performance and apply basic optimizations.
- Write simple network servers.
Diversity and inclusion
CS61 welcomes a diversity of thoughts, perspectives, and experiences. The CS61 teaching staff respects our students’ identities, including but not limitedto race, gender, class, sexuality, socioeconomic status, religion, andability, and we strive to create a learning environment where every studentfeels welcome and valued. We can only accomplish this goal with your help. Ifsomething is said in class (by anyone) or you come across instructionalmaterial that made you uncomfortable, please talk to the instructors about it(even if anonymously).
Assignments
Programming assignments are a critical part of the course. There will be six assignments handed out at one to two week intervals. We encourage collaboration among students (subject to the collaboration policy below), but all assignments will be graded based on individual turnins. This is a change from previous years.
Assignments will be due at midnight (11:59:59pm Eastern) on the due date.
Late work and your health
Each student has 144 free late hours which can be applied to anyof the assignments. (That’s a total of 6 late days.) This means thatall assignments can be late by a cumulative total of 144 hours withoutpenalty. If you wish to take late hours, you must add a prominent "DONOT GRADE" notice to the top of your README.md. This notice must bevisible on the grading server from the assignment deadline until yoursubmission is ready for grading.
Significant penalties will kick in after the 144 late hours areexhausted, such as a letter grade off on over-late assignments per 4hours of additional lateness, down to a minimum of F.
Skipped assignments receive a zero, not an F. Zero is far worse than F(in the letter grading system F is often represented as 50%). Youdon’t want zeros on any assignment: a great way to get a bad classgrade is to skip an assignment. It’s better to complete and turn inassignments even if you’ve already used your late hours.
If you find yourself struggling, please contact the instructors assoon as you feel able; and if you have a health condition that affectsyour learning or classroom experience, please contact us so we canseek accommodations. We do not generally make exceptions to the latepolicy, but we work hard to help all our students complete the coursewithout overwhelming stress.
Attendance in 2020
Lecture segments will be recorded at varying times of day with rotating groupsof “active listener” students whose attendance is required (~12-16 perlecture). Over the course of the semester, each student must attend about 10lectures as an active listener (exact number to be determined). There willoften be some prep work, to get people ready for the lecture; active listenersmust complete the prep work in advance. We would prefer that active listenersattend lecture with their videos on, though we understand this may not bepossible for everyone.
You are also expected to watch the lecture segments you aren’t required toattend, either by showing up as a passive listener or by watching offline orin a listening group with course staff.
You are expected to show up for at least 2–3 synchronous hours with coursestaff per week. This includes lectures and office hours, and is a generalpolicy for all Harvard classes.
We would prefer that extension students also serve as active listeners, butunderstand that this may not be possible for all extension students. (Extension policies)
Tests in 2020
Each student will be asked to invent review questions per unit withsolutions in lieu of substantial timed tests. These review questions shouldbe modeled on the questions in our question banks. Course staff will gradeyour review questions for relevance to the class material, creativity, and theexistence of an unambiguous answer. In the first half of the class, we willprovide a round of feedback so you have a chance to fix problems with yourquestions.
We currently plan to create a final by selecting from student-written reviewquestions. Different students will have different finals.
Rationale: Prior offerings have included staff-written, timed midterms andfinals. These tests have generally been considered difficult and long and wewould like different ways to evaluate students. In addition, remote learningmakes timed tests more inequitable and harder to police. We believe thatstudent-written review questions may check individual student understanding insome of the same ways as tests, while reducing time pressure and grantingstudents some opportunities for creativity.
Collaboration: Students must not collaborate on the review questionsthey create. Students should create questions on their own. Each questionshould represent the student’s own work—no copying a question from theInternet or posting questions to the Internet, although the usual resources(book, notes, course videos, prior course material, general Internet research)may be used in the process of creating a question. Staff can help studentsevaluate whether a review question is too close to material available in thebook or on the web.
Question framework: Review questions should be written assuming open bookand open notes. Answering a question should be possible without using acomputer, but computer access and restricted Internet access would be allowed.The Internet access policy will resemble this:
The exam is open book, open note, open computer. You may access thebook, and your own notes in paper form. You may also use a computer orequivalent to access your own class materials and public class materials.However, you may not access other materials except as explicitly allowedbelow. Specifically:
- You may access a browser and a PDF reader.
- You may access your own notes and problem set code electronically.
- You may access an Internet site on which your own notes and problem set code are stored.
- You may access the course site.
- You may access pages directly linked from the course site, including our lectures, exercises, and section notes, and our preparation materials for the midterm (including solutions).
- You may run a C compiler, including an assembler and linker, or a calculator.
- You may use a Python interpreter.
- You may access manual pages.
But:
- You may not access Google or Wikipedia or anything else except as directly linked from the course site.
- You may not access Piazza.
- You may not access course videos.
- You may not access an on-line disassembler, compiler explorer, or similar applications.
- You absolutely may not contact other humans via IM or anything like it.
- You may not access solutions from any previous exam, by paper or computer, except for those on the course site.
Any violations of this policy, or the spirit of this policy, are breaches ofacademic honesty and will be treated accordingly. Please appreciate ourflexibility and behave honestly and honorably.
Grading
A tentative grading breakdown for College students follows.
- 50% assignments
- 20% review questions
- 15% final
- 15% participation (lecture, office hours, Piazza)
Problem set collaboration
CS 61 labs may be completed in groups, but we expect every student to turn ina separate code repository. Here’s what that means and why we’re doing it.
Collaboration is an important part of CS 61. Talking through their code with partners and other students leads to less stress and loneliness and easier debugging.
But partner dynamics can hurt too. We want every student to have worked on every problem set, but previously some partners have shirked work or alternated assignments (“you do pset 4 and I’ll do pset 5”), which isn’t fair to others and reliably causes problems. We want each student to understand the entirety of the work they turn in. Partner concerns have also led us to put more grading weight on exams.
We seek a happy medium. We want to allow strong collaboration within the class, but avoid the pathologies of group turnin. So we ask every student to turn in separate code for each problem set. Students may create code together, and may share code, but code submissions must not be wholly identical and each student must understand all code they turn in. A good way to ensure this is for students to type in their solutions individually, rather than cutting and pasting. Another good way would be for partners to discuss ideas and code and help each other debug, but write their code themselves.
Collaboration is encouraged on all aspects of the course except exams. You are welcome to communicate with your classmates about strategies for solutions and about specific bugs, and you are welcome to use Internet resources for general information. However:
- You must not ask questions on Stack Overflow, paper.camp, or any similar site. (Of course, if you search for some C++ problem, Stack Overflow answers may come up—just don’t ask questions yourself.)
- You must not use solutions from past (or future) years.
- Cite help. If a classmate, other collaborator, or online resource helps you, acknowledge this in your assignment. Name the helpers and briefly describe how they helped. (You do not need to cite help from course staff or resources directly linked from this site.)
Do not post your solutions in a public place.
Embedded EthiCS
CS 61 participates in the EmbeddedEthiCS effort collaborativelylaunched by faculty from CS and Philosophy. In addition to the technicalknowledge and skills one gains through a CS education, today’s computerscientists need to reason ethically about the design decisions they make. Thecourse instructors and a graduate or postdoctoral fellow in Philosophy willpresent a unit in this course that exemplifies how you can identify ethicaland social issues, think rigorously about those issues, design systems thatthoughtfully address those issues, and communicate clearly the designdecisions and tradeoffs made.
