CSE 333 24su Systems Programming
Information and Syllabus

Logistics and Contact Information: See the main course web site www.cs.washington.edu/333/. Look there for information about the course including meeting times, staff, office hours, communications, etc. The CSE 333 Canvas pages will only be used to store lecture recordings, for links to zoom meetings (particularly office hours), and for gradebook record keeping. All other material is on the main website.

Communications: A discussion board is linked to the course home page so we can keep in touch outside of class meetings. Please participate.

You should use private messages on the discussion board or the course mailing list to contact the staff about anything that is not appropriate for a public message, including specific questions about your assignment solutions or any personal issues that you need to discuss with the course staff.

[ prereqs | topics | class | assignments | exercises | exams | grades| texts| policies ]


Requirements

Prerequisites


Approximate topic list


Lectures and Sections

For times and locations, see the course website or the UW Time Schedule. Lectures will be recorded using panopto. See the course canvas page for links. Sections will not be recorded, although videos of some tutorial material may be provided.

Although lectures will be recorded, this class is not a distance-learning or hybrid class. Recordings are intended for review, or to help when unavoidable absences such as illness occur, not to replace class attendance. Recent experience has shown that significant numbers of students who regularly miss class struggle with the material, find it hard to keep up, and do not do as well in the course. You should plan to attend class regularly.

Lecture Activities

Part of your in class grade will be lecture activities, answering questions that are asked in lecture. These activities are meant to be done in lecture; if you need to make up a lecture activity for a class you missed for a particular hardship, you can email the staff mailing list and we'll try to accomodate. Since life can bring unexpected challenges, we'll drop the three lowest participation scores.

Assignments and Computing Environment

This course is designed to give you substantial experience with programming. There will be four major programming assignments during the quarter; the assignments are designed to build on top of each other, so it is in your interest to make sure that earlier assignments are rock-solid.

All of our assignments and exercises assume you will be using the current Allen School Rocky Linux environment with gcc/g++ version 11. There are three ways to do this:

Regardless of where you develop your assignments, we will test and grade them on CSE lab machines using gcc/g++ 11, so you must ensure that your code works properly there. Different linux distributions and linux-like systems (MacOS, for example), while fundamentally the same, have enough subtle differences in libraries and header files that code developed elsewhere has a strong probability of failing to work correctly when tested on CSE systems.


Exercises

Great programmers write great code. People become great programmers writing lots of code and learning from the experience. We will be assigning a mandatory programming exercise with most lectures, due before the next lecture. These will be relatively short and simple, but they will reinforce the material from the lecture. We will grade them and provide feedback and sample solutions, but the grading will be course-grained: "check plus", "check", and "check minus". But because our grading infrastructure uses numbers for all things, exercises will be given numeric scores as follows:

We expect 0's and 1's to be rare, and 3's to be less common at first, with more 3's as the quarter progresses and earlier feedback is taken into account. In recognition of the fact that learning involves making mistakes and learning from them, we will drop your lowest exercise score (out of a planned 21 activities) from the course grade calculation. As with larger assignments, exercises will be graded and evaluated using the CSE linux environment.

A Word About Code Quality and Legibility ...

The code that you submit for exercises and homeworks must be high-quality and easy-to-read. To help you learn what "quality" and "legibility" means, we will be using a variety of automated tools (eg, cpplint, Valgrind) and online guides (eg, the Google C++ guide, linked on our resources page). In this course, we take quality very seriously and will weight these scores appropriately.


Exams

We will have one midterm exam and a final exam. These exams will both be held outside normal class hours, and all students in both lectures will take the exams at the same time. Dates and times will be listed on the course calendar as soon as we have confirmed details. The primary purpose of exams is to provide an opportunity to review and solidify understanding of course material, especially concepts that are not covered comprehensively in programming assignment or exercise code.


Grades

The initial plan is the following. We reserve the right to make reasonable adjustments to this as the quarter evolves:

Project assignments are assigned two scores: one for program operation (correctness) and one for code quality (style). These two scores are converted to a percentage and weighed roughly equally in the overall project assessment, even though the raw point scales may be quite different.

If you discover an error in grading, please bring it to our attention within one week after the assignment or project is first returned.


Texts

There are no strictly required texts for this courses. Most people will find it useful to have both a C and a C++ reference; suggestions are given below. We strongly recommend that you have a copy of the C++ Primer as C++ is a big, complex language and it is hard to understand how it fits together from google searches and stack overflow snippets and folklore.

Many of these books are freely available to UW students through the UW Library's subscription to Safari Books Online. Go to https://www.oreilly.com/, click sign-in at the top right, and enter your @uw.edu email address. You will then be directed to a standard UW netid login, after which you can access everything on the site.

Strongly Recommended (i.e., basically required)

Suggested

The course web resources page has links to several useful C, C++, and Linux reference and tutorial sites.


Policies

(Many of these policies are taken verbatim from other CSE courses and University policies.)

Accommodations: Please refer to the university policies regarding accommodations and religous accommodations. Those policies apply in this class as everywhere else at UW. Please contact the instructor, DRS, or the course staff as needed so we can help.

Late Policy: The standard CSE 333 late policy is as follows: Project assignments are expected to be done on time, however we realize that occasionally a bit of slack is needed for unexpected problems or to get rid of that "last" bug. For the entire quarter, you may have four free "late days". You are strongly advised to save them for emergencies. You may not use more than two for the same assignment, and on group projects (if we have any) you may only use late days if all members of the group have them available, and all members of the group will be charged for each late day used. They must be used in 24-hour (integer) chunks. If you are not finished with an assignment and have no more remaining late days you should turn in your best effort for partial credit either on time or after using any available late day(s). This policy may not be the same as in other classes. You are responsible for understanding it if you choose to submit late work.

For exercises, we will not accept any late; you must turn them in on time.

However, there are always truly unusual situations that require some flexibility. We will do our best to work with you if you are having problems, or if unexpected emergencies or illnesses occur. Please contact the course staff as soon as you can if you need help, or advice, or if there are other things we can do, especially if you find it will be difficult to meet deadlines for reasons beyond your control. Please do not wait until the problem becomes more difficult or impossible to solve - let us know when the problems occur. We'll do what we can to work with you.

Cheating vs. Collaboration: Please see the separate discussion of Academic Integrity. You are expected to read and understand every word in that document. Ask first if you have any questions.

Collaboration is a very good thing. On the other hand, cheating is considered a very serious offense and is vigorously prosecuted. Vigorous prosecution requires that you be advised of the cheating policy of the course before the offending act.

For this course, the policy is simple: don't cheat. You know it when you're doing it. We'll recognize it when you do it. As an easy example, sharing assignment solution code with each other is cheating, as is copying homework solutions from any source. As another easy example, relying heavily on some resource (e.g., some example code you found on the Web) without attributing is cheating.

That said, collaborating is, for most of us, a very effective way to learn. Learning isn't cheating. Helping each other write code that are not detailed parts of assignments or exercises isn't cheating. Working with others to discuss ideas, designs, and possibilities isn't cheating. Misrepresenting that you've learned something, or done the work that implies you've learned something, almost certainly is.

Reasonableness: No set of rules can apply perfectly in every setting. We will make reasonable exceptions, and in return, we expect you to be reasonable as well.