Syllabus
Course website: http://www.cs.washington.edu/503/
Class meetings:
Tue & Thu 11:00-12:30, room EEB 025
Lecturer: Michael Ernst
http://homes.cs.washington.edu/~mernst/
Even outside the official office hours, I welcome discussions with students.
Please don’t be shy about contacting me if you wish to meet!
TA: Calvin Loncaric
In many years CSE 503 is a broad course that covers all aspects of software development. This year’s offering is more narrow but deeper.
For a list of specific topics that may be covered, see the course webpage.
Grades will be assigned based on the project (80%), class participation (20%), and instructor discretion (variable). As this is a graduate class, the class is likely to be A-centered, but students are not guaranteed a grade of A.
CSE 503 is a graduate paper-reading seminar. Each class session will begin with a brief discussion and presentation of material, after (or during) which the floor will be open to rebuttals, discussion of related work, criticism, brainstorming about follow-on research, etc. We will all learn from the conversation, even the instructor. We will all have questions and confusions about the material, even the instructor. You are required to be not a a passive listener to lectures but an active participant in the discussion.
To help you prepare, you will write a one-paragraph commentary on each paper, and submit it at least 24 hours before the class meets to discuss the paper. You will post your commentary to the course webpage for viewing by the instructor and by other students. The commentary should reflect your understanding and analysis of the issues raised by the paper, and should also help direct (both your and others’) preparation for in-class discussion.
You may write the commentary in whatever style you prefer that meets the goals listed above. One good format for the commentary is to critique the paper, listing the following three points: its biggest contribution (and, briefly, why that result was not already obvious), its biggest mistake (in motivation, methodology, algorithm, data analysis, conclusions, or some other area), and the biggest question that it raises (or the most interesting and important follow-on work that it suggests). Another acceptable format is to summarize the paper, describing its thesis, approach, and conclusions, and stating why it is significant. The commentary should also list questions that you have about the paper, such as about technical points or connections to related work. For other ideas about how to critique a paper, see http://homes.cs.washington.edu/~mernst/advice/review-technical-paper.html.
It’s OK if you read the paper and there are issues you do not understand. Please ask questions about those issues — both in your summary and in class — and we will all gain by the discussion. It’s best to explain why something makes no sense to you. For example, don’t just say, “I didn’t understand section 2”, but state where there is a logical fallacy or a conclusion that does not follow or a term that is not defined. The lecturer will use these questions to help shape the lectures.
I also encourage you to use the summaries to ask questions. If you have a question, it is likely that many other people have the same question but are too shy (or vain, or insecure) to ask it; they will appreciate your raising the point. However, do come to class prepared: carefully read the paper and get as much as you can out of it on your own. Doing so will make the class time that much more productive.
You will have access to all the other students’ submissions. Please read them, because reading the other summaries is a good way for you to get perspective. You can see what you missed (or what other people missed), and whether you agree with their take on the key ideas. It will help to make the class sessions more productive.
Please submit your summary in PDF form, and include your name.
Each student will present one paper during the semester. The presentations will be done by pairs of students if there are enough students registered. Presenters will meet with the lecturer a week before the class meeting to receive feedback and improve their presentation. You should come to that meeting prepared with questions, not just expecting to run through all of your slides. The goal of your presentation should be that the class understands the main ideas afterward. (The goal of your presentation is not to prove that you know the material!)
A separate document describes the project.