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 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 ]
Several
practices embody courage. One is the commandment to always
design and code for today and not for tomorrow. This is an
effort to avoid getting bogged down in design and requiring a
lot of effort to implement anything else. Courage enables
developers to feel comfortable with refactoring their code
when necessary. This means reviewing the existing system
and modifying it so that future changes can be implemented
more easily. Another example of courage is knowing when to
throw code away: courage to remove source code that is
obsolete, no matter how much effort was used to create that
source code. Also, courage means persistence: A programmer
might be stuck on a complex problem for an entire day, then
solve the problem quickly the next day, if only they are
persistent.
(Source:
Wikipedia, Extreme Programming)
For times and locations, see the course website or the UW Time Schedule. Lectures will be recorded on 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.
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 9. There are three ways to do this:
attu.cs.washington.edu cycle servers;
The Allen School Rocky Linux machines have gcc/g++ versions 8 and 9 available.
Version 8 is the default, but for all of our work we will be using version 9. The best way to
configure the correct version is to execute the command touch ~/.gcc9
in a terminal window, then log off and log back on. When this marker file is present, the
scripts that execute during logon will configure things to use gcc 9. You should check that
the right version is set up by typing gcc -v in a termnal window. This setup only
needs to be done once and after that you should get the correct gcc version each time you log on.
It does need to be repeated once for the attus and for the home VM if you use both
since they each have separate file systems and home directories.
Regardless of where you develop your assignments, we will test and grade them on the CSE lab machines or attu using gcc 9, 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.
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, but the grading will be course-grained, roughly as follows:
We will have one midterm exam and a final exam. The dates will be listed on the course schedule, though the midterm date is subject to change (with reasonable advance notice given). 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.
The initial plan for 22sp is the following. We reserve the right to make reasonable
adjustments to this as the quarter evolves:
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 sign in with your uw.edu email address to access them.
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, the last couple of years have been very unusual and have been difficult for many of us in various ways. 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. 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 it in your turnin is cheating.
That said, collaborating is, for most of us, an effective way to learn. Learning isn't cheating. Helping each other write programs that are not assignments or exercises 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.