This page outlines general academic integrity policies used by many courses in CSE. If a course declares its own academic integrity policy, that policy supersedes the information found on this page.
In the School of Computer Science & Engineering, we take Academic Misconduct seriously and expect you to do the same. The good news is that the vast majority of you will do so. The bad news is that historical evidence indicates that some students will submit work that is not their own, shortchanging not only their own learning but undermining the atmosphere of trust and individual achievement that characterizes CSE's academic community.
Historically, CSE courses account for a large percentage of all Academic Misconduct cases at the UW each year, even though our courses represent only a much smaller percent of the student enrollment. The purpose of this page is to make our expectations as clear as possible in the hope that we will reduce the number of Academic Misconduct violations that occur. Although most violations involve program code, the expectations apply to any work done for a course. The basic principle under which we operate is that each of you is expected to submit your own work. In general, any activity you engage in for the purpose of earning credit while avoiding learning, or to help others do so, is likely to be an act of Academic Misconduct.
As a particular example, attempting to take credit for someone else's work by turning it in as your own constitutes plagiarism, which is a serious violation of basic academic standards. From the attention that the school pays to the Academic Misconduct issue, some of you will get the idea that any discussion of assignments is somehow a violation of academic principle. Such a conclusion, however, is wrong. In CSE courses it is usually appropriate to ask others -- the TA, the instructor, or other students -- for hints and debugging help or to talk generally about problem-solving strategies and program structure, as well as lecture and textbook content. In fact, we strongly encourage you to seek such assistance when you need it. The important point, however, is embodied in the following rule:
Rule 1: You must indicate on your submission any assistance you received. If you make use of such assistance without giving proper credit, you may be guilty of plagiarism.
For programs, proper citation usually takes the form of comments in the program. The instructor might indicate other methods of acknowledging help received, especially for other types of assignments. It is also important to make sure that the assistance you receive consists of general advice that does not cross the boundary into using code or answers written by someone else. It is fine to discuss ideas and strategies, but you should be careful to write your programs on your own. This provision is expressed in the following rule:
Rule 2: You must not share actual program code with other students. In particular, you should not ask anyone to give you a copy of their code or, conversely, give your code to another student who asks you for it; nor should you post your solutions on the web, in public repositories, or any other publicly accessible place. Similarly, you should not discuss your algorithmic strategies to such an extent that you and your collaborators end up turning in exactly the same code. Discuss ideas together, but do the coding on your own.
The prohibition against looking at the actual code for a program has an important specific application in computer science courses. Developing a good programming assignment often takes years. When a new assignment is created, it invariably has problems that require a certain amount of polishing. To make sure that the assignments are as good as they can be, our school -- like most others in the country -- may reuse assignments, incorporating a few changes each time to make them more effective. The following rule applies in all CSE courses:
Rule 3: You must not look at solution sets or program code from other years, nor should you make your own solutions publicly available even after the due date. Beyond being a clear violation of academic integrity, making use of old solution sets is a dangerous practice. Most assignments change in a variety of ways from year to year as we seek to make them better. Each year, however, some student turns in a solution to an assignment from some prior year, even though that assignment has since changed so that the old solution no longer makes sense. Submitting something that solves a previous year's assignment perfectly while failing to solve the current one is particularly damaging evidence of Academic Misconduct.
Whenever you seek help on an assignment, your goal should be improving your level of understanding and not simply getting your work completed correctly. Suppose, for example, that someone responds to your request for help by showing you a couple of lines of code that do the job. Don't fall into the trap of thinking about that code as if it were a magical incantation -- something you simply include in your program and don't have to understand. By doing so, you will be in no position to solve similar problems on exams. The need to understand the assistance you receive can be expressed in the following rule:
Rule 4: You must be prepared to explain any program code you submit.
Although you should certainly keep these rules in mind, it is important to recognize that the cases that we bring forward to the University are not those in which a student simply forgets to cite a source of legitimate aid. Most of the students we charge with Academic Misconduct have committed fairly egregious violations. Students, for example, have rummaged through paper recycling bins or undeleted trash folders to come up with copies of other students' work, or have e-mailed part of all of their solutions to other students in advance of the due date.
Rule 5: Modifying code or other artifacts does not make it your own.
In many cases, students take deliberate measures -- rewriting comments, changing variable names, and so forth -- to disguise the fact that their work is copied from someone else. It is still not your work. Despite such cosmetic changes, similarities between student solutions are easy to detect -- and we have effective tools for doing so. Programming style is highly idiosyncratic, and the chance that two submissions would be the same except for changes of the sort made easy by a text editor is vanishingly small. In addition to solutions from previous years or from other students, you may come across helpful code on the Internet or from other sources outside the class. Modifying it does not make it yours.
Your instructor may choose to allow exceptions in certain obvious instances. For example, you might be assigned to work with a project team. In that case, developing a solution as a team is expected. The instructor might also give you starter code, or permit use of local libraries. Anything which the instructor explicitly gives you doesn't normally need to be cited. Likewise, help you receive from course staff doesn't need to be cited. But help you receive from the outside the course, such as from tutors, even if the tutors are paid for by the university, must be explicitly mentioned. Finally, the instructor may have additional clarifications or additions to the policies on this page.
We have no desire to create a climate in which students feel as if they are under suspicion. The entire point of the Academic Misconduct Code is that we all benefit from working in an atmosphere of mutual trust. Students who deliberately take advantage of that trust, however, poison that atmosphere for everyone. As members of the CSE community, we have a responsibility to protect academic integrity for the benefit of the community as a whole.
This policy, and the text in this page, are derived from the Honor Code of the Computer Science Department at Stanford University.
- Fifth-Year BS/MS Students
- Ph.D. Students
- PMP Students
- TA Home Page