Michael Ernst

Michael Ernst

Alexey Beall
Avidant Bhagat
Michael Hart
Anny Kong
Kaushal Mangipudi
Jacob Murphy
Kaidi Pei
Chen (Jason) Qiu
Andrew Tran
Joyce Zhou

Note: The CSE 331 staff provides a lot of information on the website. Please don't be overwhelmed. This is intended to help you, and to save you time. The material is organized by type, is cross-referenced, and is linked from the calendar when you first need it. You can also search it; the search tab in the navbar contains a Google custom search engine for this site. Also, you can always ask the course staff for help; we welcome your questions!

Staff

Office hours are listed on the CSE 331 calendar.

If the scheduled office hours are not convenient for you, then please send email to schedule an appointment. It's most helpful if you can suggest a few times that you are available. Michael Ernst's availability is on his calendar.

Contacting the staff

The course staff is here to help you. The staff is good at problem-solving, but terrible at reading minds; so please help us out by asking a question if something is not clear Furthermore, please tell us when there is a problem. Your feedback will improve the course: we can fix many problems, but only if we know about them.

Forum: The CSE 331 forums are for public discussions. We encourage all members of the class to help one another on the forums. If someone asks a question to which you know the answer, then please answer it. Helpful, friendly replies are appreciated and will contribute to the class participation part of your grade. If you are overwhelmed by the forum volume, you don't have to read all of the forum messages (the staff will disseminate any truly important information by email), but if you have trouble, are likely to find it helpful to read the forum. Please don't re-ask questions that have already been asked or answered there; search before you post. Please do not post anonymously; if the staff knows your name, they can examine your repository. To help your classmates who are reading all the forum messages, please do not post content-free “noise” messages saying just “Thanks for the post” or “You're welcome” or “Me, too” — we have had complaints about them cluttering the forum. Thanks!

Staff mailing list: Mail sent to cse331-staff@cs.washington.edu will reach the course staff. In general, do not send mail to just one particular staff member, since that staff member may be busy, may not know the answer to your question, etc. You will get a quicker answer by contacting the entire staff. And, you may get an even quicker answer by using the forum, where both your classmates and the staff can also help you. As with any message, it is professional to use a descriptive subject line. Your question might be overlooked if you reply to an unrelated message or use a generic subject like “CSE 331 Question”.

Anonymous mail: You can send an anonymous message to either the whole staff or just the instructor on Piazza. Please feel free to use this if you have something on your mind and you prefer not to include your name. Please be as constructive and specific as possible.

Mail to you: All CSE 331 email will go to your @cs.washington.edu email address. It is your responsibility to read it or to forward it to an email address that you do read.

Office Hours

Please visit the staff during office hours if you have anything you'd like to discuss about the course or course materials. If the office hours are not convenient, then send email to schedule an appointment. It is most helpful if you suggest several times when you are available.

The TAs will generally hold their office hours in a basement lab such as CSE 002 or CSE 006. Please feel free to work in the lab so you can talk to them in person when you have questions about Java or other technical details. Time permitting, they also monitor the forum while on duty, but they give priority to students who visit them in person.

You can also stop by the staff's offices, if the door is open; at the very least, you can schedule an appointment then.

How to Ask

We want to help you by answering your questions! We would much rather that you ask us than that you waste your time in confusion and frustration. Here we suggest some ways to make your question more likely to elicit a useful answer. The two key points are to explain what you know and to explain what you have tried.

If you are having trouble with a tool or with code, then be sure to include all the relevant information, and to be precise, so that others can help you. First, say what machine you are working on: the operating system, and whether it is a lab machine or your own personal computer. Then, state exactly what you did that caused the problem; this might be an action in a GUI or a command run from the command line. Also, state the exact outcome or output (not just “it gave an error”, for example), such as giving all the text from a popup message, or cut-and-pasting all the output from the command line. If your message is to the course staff, then commit your work to your Git repository and push to GitLab before you ask your question, so that the staff can reproduce the problem.

When you ask for help, do not provide a screenshot of terminal or textual output. Instead, cut-and-paste the complete text and include it. The text is easier to read, is easy to make complete (unlike screenshots which may show only a portion of the output), and is searchable.

It can be helpful (to you and to others) to create the smallest possible test case that reproduces the problem. This helps to avoid being distracted by irrelevant details. You can proceed by binary search: cut away half of the input or the program at a time until you have isolated the problem. Even if you cannot do this, do still ask your question.

If you are having trouble with a concept, then please explain as much as you already understand. Saying “I don't understand anything about X” is unlikely to be true, and unlikely to be helpful in clearing up your confusion. For example, explicitly answering these questions can be a good place to start:

For any question, an excellent approach is to logically explain why your problem seems impossible. If your code is giving a wrong answer, then state a detailed logical argument about why the observed output is impossible. If you cannot understand a statement in the readings or in lecture, then state why it is a logical contradiction (or why it is not relevant, or what part of it just makes no sense). Also, be specific about what confuses you — for instance, give a page number. It's essential to say where you have already looked — in what books or handouts, what web search (Google is often smarter than the course staff and your friends), etc. Even if you do not discover your problem, this will help others to quickly understand the confusion — for example, perhaps you are misunderstanding a particular term, or you have forgotten to account for aliasing. And, it will prevent people from suggesting something you have already tried — such an answer delays you getting the help you want.

The above may sound like you shouldn't ask a question until after you've at least tried to solve it yourself. As a general rule, that is actually good advice: sometimes you'll solve it on your own and, in any case, you can provide much better information about the problem. That information will make it much more likely that you quickly get a useful answer. Otherwise, someone might just suggest something you have already done, or might be confused about your problem.

It's great to make some headway on your problem before asking a question. But, stop when you are no longer making headway! If you get stuck, then stop wasting your time and get help from someone else. We definitely don't want you to waste your time in frustration, afraid to ask a question. Just explain what you know and what you have tried and ask the staff (or others) for help. Oftentimes there is a simple answer that can get you going again.

Finally, if you ask a question by email or in the forum and later discover the answer, then please let everybody know! This will help others, and will prevent anyone from wasting time continuing to answer a moot question.

Textbooks and readings

Readings are listed on the calendar. Please complete any assigned reading before the date on which it is listed. The lecture or section will assume that you have read the material. If you have questions, ask the staff or forum ahead of time, or ask in class.

You are responsible for all handouts on the website, including ones that are not listed on any specific date. If something does not seem relevant to you yet, then at least skim it and make a note to come back to it later. You may find unassigned reading assignments from the books useful, but they are not required.

Required Texts

Three books are required:

Some other excellent books you should consider for your reference library on software engineering are:

Why buy the textbooks?

Aren't books obsolete in the days of the Internet and widely-available programming advice? No. A good book is a well-written, clear, coherent, and comprehensive introduction to the subject material. The reason to pay for a book is for its writing and editing.

The Internet, by comparison, can be extremely useful in helping you understand a specific error message or programming problem, and I encourage you to use it for that. The right Internet site can also give you a high-level idea of a particular concept you are unfamiliar with. But, in the main, freely-available material gives only a fractured and partial view of the conceptual material — and the concepts are much more important than low-level programming details.

Everyone has been burned by overpaying for a bad book. I don't think that's the case for the required books. I own two copies of each the required books (except Horstmann), so I can keep it on my bookshelf both at home and at work. I refer to them often. I think it's well worth your while to have them on your bookshelf: you will learn much from them and will find them useful far into the future.

Compared to the value you will get from them — and to the cost of tuition and the value of your time — the books are not all that expensive. The textbooks are available on reserve at Odegaard library.

Where and When

Lecture/section

We will distribute electronic copies of the lecture slides. The slides augment but cannot replace your own notetaking during lecture and your reading of the textbooks.

Please attend the section that the registrar has assigned you, to keep the sections balanced.

Exams

There will be two one-hour exams (that is: a midterm and a final exam); see the class schedule. We provide old exams, which you may find helpful when reviewing, but remember that material covered varies from quarter to quarter.

During the optional exam review sessions, the staff will not present material or give a review of the course so far. Rather, they will answer questions that students ask. Therefore, you should study before the exam review and use it to clarify anything you're unsure of.

Policies

Grading policy

The point breakdown is subject to change.

Staff discretion
(including course participation)
5%
Homework 1 5.55%
Homework 2 5.55%
Homework 3 5.55%
Homework 4 5.55%
Homework 5 5.55%
Homework 6 5.55%
Homework 7 5.55%
Homework 8 5.55%
Homework 9 5.55%
Exam 1 15%
Exam 2 25%

When grading, the staff will use a common rubric to ensure consistency. We reserve the right to normalize grades across graders to account for remaining disparities.

CSE 331 grades each student in the class independently: we do not, for example, limit the number of students who can get a 4.0 or a 2.0. Your grade depends on you, and it does not depend on other students. If a student drops, the rest of the students' grades are not affected.

At the same time, there is no pre-determined score (e.g., 90% of all possible points) that earns a 4.0 or a 3.5 or a 2.0 or any other grade. Rather, at the end of the quarter the staff discusses each student individually. To determine the final grade, the staff relies on the English descriptions in the Sample UW Grading Guidelines, and the staff asks itself questions like “Did this student master the material?” and “If I were founding a startup, would I hire this student?” Because there is no fixed mapping between percentage scores and GPA, the staff will periodically give you an estimate of your grade to date.

The absolute number of points that you earn should not discourage you. Getting a grade of less than 90% does not mean you won't get an A, and getting a grade of 90% does not mean you will get an A. In particular, the average score on an exam is generally around 65%, but this score often translates to a B+. This low average score is by design, so that the standard deviation of student grades is large. If the standard deviation is small, then any one mistake is significant because a loss of a few points could change your grade from an A to a B or a B to a C. If the standard deviation is large, then no one little mistake has a significant impact on your grade, and your grade is a fairer measure of your understanding. Thus, having a large standard deviation (and a low average percentage) on each assignment or exam is the fairest approach for students.

Late/missing work

Collaboration policy

To successfully build a large software system requires collaboration among people who have strong individual skills. CSE 331 focuses more on your individual skills. Courses such as CSE 403 focus on the collaboration and give you experience with group work.

CSE 331 does permit collaboration. The principles of the collaboration policy are:

More details follow.

Discussion is permitted, indeed, encouraged!
You can learn a lot from others; you can avoid getting stuck; and teaching someone else can be the best way to cement your own understanding.

You may have discussions with anyone you like, including other CSE 331 students.

No materials you bring to or take away from such meetings may be turned in as (part of) your solution. In particular, you may not bring any of your code or solutions to the meeting.

You may only bring away information in your long-term memory. You must destroy any materials that you and others create during the meeting. Then, you must spend 30 minutes without thinking about CSE 331. (Watching a mindless TV show is a canonical example; this is commonly called the Gilligan's Island rule.) After that, you can use whatever you still remember.

You must write up anything you submit on your own.
Your code (which includes tests and documentation), problem answers, etc. must represent your own understanding, as explained solely by you.
You may not view other people's code or solutions.
You may not share any of your own code (including, as always, tests and documentation) with others, including bringing it to a meeting with others.

You may not allow anyone except the course staff access to your ~/cse331 directory or any other location where you keep CSE 331 code. (If you need to copy code to your home computer, use Git. If anyone else has access to that computer, learn how to use your operating system's access control mechanism.) Don't post large amounts of your code (more than about 5 lines) to the forum.

As an exception to the prohibition against viewing another student's work, you are permitted to assist another student with tool-related problems (such as difficulty using IntelliJ or git), even if such assistance results in incidental viewing of snippets of code. But, regardless, each student is expected to write and debug the assignment code individually. Debugging your code is not a tool-related problem.

You may not represent someone else's work as your own.
You must give credit where credit is due. When you turn in assignments, you must list everyone with whom you've had substantive discussions. Likewise, if you obtained a key idea from some other resource, such as a textbook or a website, then you should credit it.

You may not view and/or use any substantive material or solutions from similar assignments this term or previous terms at UW or elsewhere, including anywhere on the Internet, transcribing solutions from any other source, etc.

Familiarize yourself with the CSE, COE and UW policies on academic honesty.
If you have a question about what is allowed, ask the staff!
This policy is intended to convey the spirit of the law, fully understanding that the letter of the law may not cover everything that someone may think of. It's not effective for us to try to define a list of all impermissible activities. This approach can tempt people to look for loopholes.

Here are two examples of what is okay. it is permissible to discuss testing strategies with another student, but you may not view another student's testing code. You and other students can sketch out an algorithm or design together, but you must destroy any written materials from your meeting, let 30 minutes pass without thinking about CSE 331, and then work from your understanding (that is, from your memory).

Our policy is intended to convey the spirit of the law, fully understanding that the letter of the law may not cover everything that someone may think of. It is your responsibility to satisfy both the letter and the spirit of the rules. If any part of this policy is not clear, or if you have any questions or concerns, ask for clarification.

It's about your integrity, not just your CSE 331 grade.
Integrity is crucial to a working engineer. Computing is at the core of almost all societal systems, and its discrete nature makes it especially unforgiving. Software has been responsible for death and damage. If you cut corners in your work, or are unprepared for it, then you, too, could cause such problems. We expect you to show high ethical standards in CSE 331, and in the rest of your career. Accordingly, violation of academic honesty (for instance, by cheating or by collaboration beyond what is permitted) will be taken very seriously.

Violating the collaboration policy may result in failing the class and/or other penalties. A baseline penalty is receiving a 0 on the assignment on which you cheated, a 1.0 (letter grade) deduction on your overall CSE 331 grade, and a letter in your University file. The lecturer has sole discretion to impose greater or lesser penalties than the baseline.

We will use technological and other means to detect cheating.

Procedures

How to Submit Assignments

You will submit the implementation part of your assignments electronically, as described in the Assignment Submission document.

To receive credit for correctness, all code you turn in must compile and run when called as specified in the assignment. The staff will not adjust your output formats or otherwise debug your programs to try to get them to run. You will be given example input and output files, and often full test suites as well, so you can test your own programs before submitting them.

Your documentation must clearly indicate any shortcomings of your program. If your code does not compile, or if certain functionality is missing, and your documentation does not clearly and prominently indicate as such, then you will lose points for the omissions (as well as for the defect itself).

Diagrams which you turn in must be readable. We will not be grading on artistic merit. However, if it is not easy to understand, then you have not successfully conveyed the relevant information, and you will be graded accordingly.

Most assignments provide you with a detailed specification for the behavior of the code that you will write. It is imperative that the program you write conform precisely to these specifications. For example, your program should not write anything to either standard out or standard error other than precisely what is specified. To avoid failing the automated tests, you should verify that the spelling, phrasing, or punctuation conforms to the specification. The output of your program should furthermore be deterministic: it should not vary from run to run when presented with the same input.

In addition to providing specifications for the behavior of your program, we will sometimes provide specifications for certain classes. For such classes you are free to add private fields, methods, and constructors, but unless otherwise specified you may not add public, protected, or default-access (package) fields, methods, or constructors.

The test suites that you include with your program should run in under a minute when testing your implementation.

Your code should always build cleanly (without errors). If, at the time of submission, your code failed some test, you need to fix it before you submit the next homework or you will lose points again.

Graded Assignments

We grade assignments within one week from when they are due. In the case of late turnins, we will try to return the graded assignment within one week from when you submit the assignment.

You will receive comments on your submissions in the form of a GitLab Merge Request. Do not change the Merge Request. (But, you may change your code to address the TA comments! We expect you to do so; if you do not, you may lose points again for the same problem.) Do not reply to the Merge Request; we do not read the comments. You can contact a TA during office hours. Regrade requests are permitted, but should not be made lightly or gratuitously. They result in regrading your entire assignment.

Assignment hints

To complete assignments as efficiently as possible, and to derive the most benefit, we recommend that you:

Computer account

You must have a CSE computer account (at cs.washington.edu and a CSE Net ID. If you do not have one, contact CSE support (email support@cs.washington.edu) immediately.