Policies

Rationale

Your instructor and your fellow students expect and deserve a basic respect for the integrity of this course and an environment where we can all focus on learning. Therefore, this document establishes a clear understanding of what we all will do, with the expectation that it will never be an issue.

We want you to learn from your fellow students and discuss the course material, but the work you complete must be your own. If you are ever unclear about how to represent what work you have done, (a) ask and (b) describe clearly what you have done. If you do, the worst that will happen is you will lose some credit on an assignment. This is much better than the alternative.

Collaboration Policies

Unless otherwise stated, you are to complete assignments individually. You may discuss the assignment in general terms, but the code you write must be your own. You are encouraged to discuss ideas, approaches, concepts, bugs, etc., in English, but you may not show or give your code to anyone except this course's TAs and instructor. You are not allowed to write code with another student on an assignment or to show another student your solution to an assignment. Although the work you turn in should be your own, we do encourage you to discuss material with other students provided:

  1. You spend at least 30 minutes on each and every problem (or programming assignment) alone, before discussing it with others.
  2. Cooperation is limited to group discussion and brainstorming. No written or electronic material may be exchanged or leave the brainstorming session.
  3. You write up each and every problem in your own writing, using your own words, and fully understanding your solution (similarly you must write code on your own).
  4. You identify each person that you collaborated with at the top of your written homework or in your README file.

Copying someone else's homework is cheating (see below), as is copying the homework from another source (the web, other classes, previous course offerings, etc.).

Cheating

Cheating is a very serious offense. If you are caught cheating, you can expect a failing grade and initiation of a cheating case in the University system. Cheating is an insult to other students, to the instructor, and to yourself. If you feel that you are having a problem with the material, or do not have time to finish an assignment, or have any number of other reasons to cheat, then talk with the instructor. Copying the work of others is not the solution.

To avoid creating situations where copying can arise, never e-mail or post your solution files. You can post general questions about interpretation and tools but limit your comments to these categories. If in doubt about what might constitute cheating, send the instructor email describing the situation. For more details, see this Academic Misconduct web page.

Lateness

All parts of an assignment must be received by the stated deadline in order for the assignment to be counted as on time. Each student in the class will be given a total of two "late days" (a late day is 24 hours of lateness). There are no partial days, so assignments are either on time, 1 day late or 2 days late. Once a student has used all of his or her late days, each successive late day will result in a loss of 20% on the assignment. Note: In the case of any written assignments that is normally to be turned in as hardcopy, you would need to create an electronic version and email it to us within 24 hours of the deadline to have it considered only one day late. You may not submit any portion of any assignment more than 3 days after its original due date.

Written assignments are due promptly at the beginning of lecture. If you cannot attend lecture, please arrange to turn in your homework earlier to the instructor or have a classmate turn it in for you at the beginning of lecture. Programming projects will be submitted electronically by the deadline announced for each assignment. Occasionally exceptional circumstances occur. If you contact the instructor well in advance of the deadline, we will consider such cases.

Re-grade Policy

If you have a question about an assignment or exam that was returned to you, please do not hesitate to ask a TA or the instructor about it. Learning from our mistakes is often one of the most memorable ways of learning. If, after discussing your question with a TA or the instructor, you feel that your work was misunderstood or otherwise should be looked at again to see if an appropriate grade was given, please submit a written re-grade request as follows:

  1. Along with the original version of the assignment you wish to have re-graded, include a written summary (which can be neatly handwritten) describing why the work should be looked at again.
  2. Submit it to the TA who graded your assignment. (That TA will either take care of it directly or pass it to the lead TA for that assignment, who will either take care of it directly or pass it to the instructor.)
  3. Re-grade requests must be submitted within a week of the time when the assignment is returned.

When a written assignment, programming project, or test is re-graded, the entire work may be re-graded. This means that while it is possible to gain points, it is also possible to lose points.

Overall course grade

Your overall grade will be determined as follows (subject to change if necessary, but change is unlikely):

Grading guidelines for programming assignments

See also Programming Guidelines for the course.

For each project the, approximate and subject-to-change grade breakdown is:

The reason why "so few" points are allocated toward program correctness and error-free compilation is because students who have gotten past CSE143 are accomplished enough to know how to get their code to compile and run against the general input (although testing "boundary conditions" is a skill that students should aim for). Program correctness and error-free compilation is neither a fair nor discriminating measurement of project quality.

The two biggest discriminating factors among CSE373 students are program design (such as style and architecture) and analysis (the README/writeup), which is why these factors are heavily weighted. CSE373 is a course about data structures and the tradeoffs made during algorithm/data structure/abstraction design, so putting additional weight on program design, and questions about algorithm analysis and weighing tradeoffs, is more in keeping with the course goals.

Feedback to the Instructor

If you would like to send a message to Steve Tanimoto, a UMail form has been set up for that. It is restricted to UW students, so it asks you to authenticate with your UWNetID. However, you will be given a choice as to whether or not your identity is passed on to the instructor. Here's a link to the UMail form.