Things that are NOT OK

• Issues of Time and Procrastination are not an excuse:
  • "I have finished my programming assignment in the lab and have an adrenaline rush, as well as being extremely happy. My best friend in the class, who has not finished the assignment yet, pokes me on the shoulder and sniffles. She tells me that she is still stuck on figuring out the algorithm for how to finish the project. I show her the code on my screen, eager to prove that I know how to do the assignment, while her lightening fingers take it all down."
  • has done little to no work, if it his/her first day in the lab for example, the day before a PSA is due
• Lazyness
  • ask for help after like 5 minutes of looking at it
  • calls another person over the phone or in the lab and asks them how to do it
  • not exhausted your own resources of finding the bug
• Telling rather than Helping Learn
  • physically typing on someone's keyboard, because Peter would not learn what he did wrong in the code and understand how that simple change fixed the error
  • simply tells the other what to do
• Collaborate before Getting Started
  • discuss plans before start working...the confident person has shared all their plans for how to do the program and the other person now has all the same ideas without trying to figure it out on their own
  • let you see what they did for there method to help you get started.
• Help on parts not yet done/many parts
  • If Student A asks B for help on a section that B has not completed yet, that is "crossing the line".
  • has a bug that is a fundamental part of the program which requires changing multiple lines of code.
  • if the debugging involves errors in most parts of the program so that none of the program is executing. This is because then a peer reviewer would have to go through and understand all parts of the students program and would see exactly how they did their work.
• Copying
  • Combining bits and peices of code to create a finished peice. This includes anything originally created by the other student.
  • Student A and Student B both work together to do the PSA assignment as if it was still pair programming. However, before each student submits it, they change the names of their variables and do other slight altercations to prevent from getting caught submitting the same code.
  • email their code to Student 2

-->