Michael Ernst
Brian Burg
Jake Nicholson
Will Pitts
Contents:
Important: All students must run student-setup by 8pm on Monday, January 3 (the day of the first lecture). This sets up your directory so that the staff can distribute problem sets to you. If you do not do this on time, then you will be delayed in receiving your first problem set.
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 | Phone | Office Hours | Location | |
| Lecturer | Michael Ernst | mernst@cs.washington.edu | CSE 562 | 206-221-0965 | Wed & Thu 9:00-10:00, or see calendar | CSE 562 |
| TAs | Brian Burg | burg@cs.washington.edu | CSE 362 | 206-685-3871 | Mondays 4:30-5:30pm, Fridays 10:30-11:30am | CSE 002 |
| Jacob Nicholson | jtn75@cs.washington.edu | n/a | Thursdays 11:00 - 1:00pm | CSE 002 | ||
| William Pitts | pittsw@cs.washington.edu | n/a | Tuesdays 11:30-1:20pm | CSE 002 |
Office hours are subject to change.
If the scheduled office hours are not convenient for you, then you can always 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, and by telling us when there is a problem.
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 answer it. Helpful, friendly replies are appreciated and will contribute to the class participation part of your grade. You are responsible for reading all of the forum messages. Please don't re-ask questions that have already been asked or answered there. 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". They contribute nothing, and we have had complaints about them cluttering the forum. Thanks!
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 will get an even quicker answer by using the forum, where your classmates 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.
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 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 hold their office hours in CSE 002. 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.
If you are unsure whom to ask a particular question, see the information below.
It's usually better to ask a question after you've tried to solve it. Sometimes you'll solve it on your own and, in any case, you can provide more information about the problem and what you've already tried. 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.
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 located the problem.
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). Also, be specific about what confuses you &mdash for instance, give a page number. 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, or the like.
All of this advice about how to gather information about your question does not mean that we discourage questions. Quite the contrary: sometimes there is a concept that you couldn't be expected to understand already. We would much rather that you ask us than that you waste your time in confusion and frustration! That said, we do want you to learn to help yourself, and to ask questions (in CSE 331 and later in your career) that are specific, that show that you have already tried to answer, and that are thus more likely to elicit a useful answer.
Here are some examples of questions and good ways to go about getting answers.
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.
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 the 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.
Your programming ("lab") work is done on your own time. either on IWS or using your own personal machine. Since both lectures and sections in CSE 331 tend to focus on conceptual material pertaining to software engineering rather than particulars of how to use the Java language, this term we are offering optional laboratory exercises. These sessions are optional and ungraded, but they will help you to understand and use the Java language and tools more effectively.
Lab sessions will involve a one-hour exercise that introduces you to some tool (such as editing environments, compilers, debuggers, and profilers) or to some aspect of the Java language (such as inheritance and the Swing library). TAs will be on hand to help you during their lab hours. You can work in pairs or groups on the labs to help you learn from each other: your styles, little tricks about programming, using the environment, etc. You can also get to know other students; we encourage you to work with many different people.
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.
| Staff discretion (including course participation) |
5% |
| Problem set 0 | 4% |
| Problem set 1 | 8% |
| Problem set 2 | 8% |
| Problem set 3 | 8% |
| Problem set 4 | 8% |
| Problem set 5 | 8% |
| Problem set 6 | 10% |
| Problem set 7 | 8% |
| Problem set 8 | 8% |
| Exam 1 | 12.5% |
| Exam 2 | 12.5% |
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.
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, the staff discusses each student individually. To determine the final grade, we will ask questions like "Did this student master the material?", "If I were founding a startup, would I hire this student?", and the English descriptions in the Sample UW Grading Guidelines.
Slack days. We will allow you two slack days during the quarter. You can use these both on one assignment, or one on each of two different assignments. A "day" means 24 hours from the original due date/time. You must notify the staff, by the due date/time, that you are using a slack day, and include your CSE net ID in your email.
As an an example, suppose that you have a problem set 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 problem set by Friday at 5:00pm.
You cannot use slack time for PS0 or returnins. Also, slack days are atomic; you cannot split up a slack day and submit each of three problem sets 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:
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.) 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 problem set code individually.
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).
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.
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.
You will submit the implementation part of your problem sets electronically, as described in the Problem Set 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 problem sets 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 often 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 problem sets 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 problem set 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 problem set submission, then later submitted a correct program, and further suppose that student Hare received 70/75 points on the first problem set, 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 Problem Set Submission document for details about the procedure for turning in (and re-turning in) a problem set.
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:
January 6, 2011: Added weights for problem sets 7 and 8 to the grading policy.