Michael Ernst
Contents:
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; for example, add site:http://courses.cs.washington.edu/courses/cse331/13sp/ to the search terms of a Google search. Finally, you can always ask the course staff for help; we welcome your questions!
Important: All students must run student-setup early in the quarter (details are forthcoming). This sets up your directory so that the staff can distribute assignments to you. If you do not do this on time, then you may be delayed in receiving your assignments.
If you wish to take the course but are not registered (you are on the overload list or wait list for the course), then please contact the lecturer on the first day of the quarter. If you delay, you may not be able to add the class (and even if it's possible, late adds create extra work for the staff). Thanks!
| Title | Name | Office Hours | Location |
| Lecturer | Michael Ernst | Wed 3:15-4:15, or see his calendar | CSE 562 |
| TAs | Tristan Huber | Thu 4:30-5:30 | CSE 006 |
| David Mailhot | Tue 12:15-1:15 | CSE 006 | |
| Jackson Roberts | Thu 3:30-4:30 | CSE 006 | |
| Connor Smith | Mon 3:00-4:00 | CSE 006 |
Office hours are subject to change; see the CSE 331 calendar for the most up-to-date information.
If the scheduled office hours are not convenient for you, then you can always send email to schedule an appointment; it's most helpful if you can suggest a few times that you are available. Or, stop by if the door is open; we may not have time then, but can at least schedule an appointment.
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. Feedback will improve the course (at least in the future ☺) ... 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. 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; “CSE 331 Question”, or replying to an unrelated message, is likely to get your question ignored.
Anonymous mail: You can also send anonymous email to either the whole staff or just the instructor. 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.
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.
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 SVN repository so that they can reproduce the problem.
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.
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.
A reading quiz is generally due at 2am that day. Some people find
it convenient to read ahead and do a week's worth of reading quizzes over
the weekend, and others prefer to do the reading the day before the
lecture. It may be less confusing to access the reading quizzes from the
calendar rather than directly from Catalyst.
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.
Three books are required:
Some other excellent books you should consider for your reference library on software engineering are:
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.
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.
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.
The point breakdown is subject to change.
| Staff discretion (including course participation) |
5% |
| Reading quizzes | 5% |
| Assignment 0 | 5.55% |
| Assignment 1 | 5.55% |
| Assignment 2 | 5.55% |
| Assignment 3 | 5.55% |
| Assignment 4 | 5.55% |
| Assignment 5 | 5.55% |
| Assignment 6 | 5.55% |
| Assignment 7 | 5.55% |
| Assignment 8 | 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 days. We will allow you four late days during the quarter. You can use no more than two late days per assignment. A “day” means 24 hours from the original due date/time. Before the due date/time, you must send mail to cse331-lateday@cs.washington.edu that you are using a late day, and include your CSE net ID in your email. (Notification of a second late day needs to be received before the new (extended) due date/time.)
As an an example, suppose that you have an assignment that is due on Thursday at 5:00pm, but you need extra time. You tell the staff by 5:00pm on Thursday, and you can turn in that assignment by Friday at 5:00pm.
You cannot use late time for HW0 or returnins. Also, late days are atomic; you cannot split up a late day and submit each of three assignments 8 hours late.
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.
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 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 Subversion. 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 Eclipse or SVN), 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 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.
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.
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.
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.
After your assignments have been graded, you will submit a corrected version of the code. You must do this even if you received complete correctness credit for the original submission. We reserve the right to add new tests to the staff test suite, after the assignment is originally due but before it is re-due.
The resubmitted programs are graded on correctness only, and there is no partial credit. You don't have to expand documentation, fix style problems, etc. (although doing so might simplify the task of correcting your program!). The regrade is worth 1/4 of the total grade for the assignment, so failure to resubmit your program will mean you can't get more than 75/100, even if everything else was perfect.
The returnin system runs all of the staff tests. However, the returnin report only contains the first test that fails along with a partial stack trace. On script-based tests, the returnin report will only show the difference between the expected output and the output produced by your program; it will not include the test input. The goal is to encourage you to use reasoning and testing to find errors, just as you will in the real world.
For example, suppose that student Tortoise received 60/75 points on the first assignment submission, then later submitted a correct program, and further suppose that student Hare received 70/75 points on the first assignment, but did not bother to fix the problems in the submission. Then after adding the returnin points, Tortoise's final grade would be 85/100, while Hare's would be 70/100.
The automated returnin results are not intended to replace, or even to supplement, your own test cases. They merely help the staff evaluate the correctness of your solution. You only get to see the first failure because we want to find out how many errors remained in your program when you believed it was completely correct. It only runs periodically because you shouldn't need or expect an instantaneous result (the staff does not encourage last-minute work). These mechanisms, plus having only 3 free tries, encourage you to get your program test suite right. If you are having a lot of trouble with a piece of code, consider throwing it out and starting from scratch; that might be a more effective way to get correct, functional code than a long debugging cycle.
See the Assignment Submission document for details about the procedure for turning in (and re-turning in) an assignment.
We will return graded assignments to you 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.
To complete assignments as efficiently as possible, and to derive the most benefit, we recommend that you:
Nothing yet.