$msg = ""; $myaddress = "sacha" + "@" + "sachachua.com"; $page = "2003.10.10.php"; $page_title = "2003.10.10"; $page_updated = "2004-11-2106:44:1306:44:13-0500"; $maintainer = "sacha" + "@" + "sachachua.com"; require_once "include/calendar.php"; require_once "include/planner-include.php"; require_once "include/header.inc.php"; ?>
|A1||X||By 2003.10.10, write an abstract/paper for AlternativeTeachingMethodsInIntroductoryComputerScience (E-Mail from manny <email@example.com>)|
|A2||X||Write the second draft of the abstract (AlternativeTeachingMethodsInIntroductoryComputerScience)|
|A3||X||Write the first draft of the abstract (AlternativeTeachingMethodsInIntroductoryComputerScience)|
|A4||X||Transfer my notes to the binder (AlternativeTeachingMethodsInIntroductoryComputerScience)|
|A5||X||Write UML multiple-choice questions (TeachingWork)|
|A6||X||Prepare the class diagram for the C++ exam (TeachingWork)|
|A7||X||Write the object-oriented part of the C++ exam (TeachingWork)|
|A8||X||Write the algorithms/tracing part of the C++ exam (TeachingWork)|
|8:30||10:30||Write CS123 exam|
|11:30||15:00||Write the abstract for AlternativeTeachingMethodsInIntroductoryComputerScience|
|15:00||17:30||Write evaluations; not done yet; siiiiiiigh|
|17:30||19:00||Write process review|
|17:00||21:00||The Blue Panthers plan to use the lab f223 on Friday from 5-9pm..|
|Chua, Sandra Jean V.||Ateneo de Manila University|
|Carreon, Mario T.||University of the Philippines|
From: "Romel T. Tarin" <firstname.lastname@example.org> Subject: RE: Linux Expo To: "'Sacha Chua'" <email@example.com> Date: Fri Oct 10 13:27:34 2003 +0800 yes... =) -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] Sent: Wednesday, October 08, 2003 7:52 PM To: Romel T. Tarin Subject: Re: Linux Expo "Romel T. Tarin" <firstname.lastname@example.org> writes: > sacha, are you girl or gay? Does it matter?
2. Being a TA myself (CS, though), I tried the following approach - every student writes the names of the students around him, in all 8 directions, in a specially drawn 3x3 box. Now, this killed 99% of cheating, as we TAs could get a quick verification of cheating suspects. It also helped us recognize cheating, since we could check the tests in the order of seating. This, coupled with Tal's method, could probably locate almost all cheaters.
Working alone is prone to getting stuck at one place and not being able to move on, whereas when you work with a partner (or partners), there's a potential for a different perspective, which almost always helps. I found that I learned a lot simply from hearing a different take on the problem (usually, after getting stuck in solving it :) as opposed to spending hours agonyzing over a stumbling point and possibly not really advancing from it, thus learning very little from the assignment. Furthermore, many people learn a lot by just discussing the problem, as it forces them to think along paths their brains would not take if they were left to themselves; many things fall into their place and sink in much better in this fashion (for example, how many of you have come up with an answer to a tough question while explaining your question to a friend?). And let's be realistic, in the real world, many things are done collaboratively and are beyond any single person.
Another fun thing to do:
In one of my composition classes during my freshman year a student copied a paper verbatim from Cliff's Notes. The teacher and everyone else in the class had read the Cliff's Notes for the material, so this was a really dumb move.
The teacher's solution: give her a really high grade and have her read her paper aloud in class as an example of an outstanding paper.
As she read the paper it became obvious to everyone in the class what she had done and she immediately approached the teacher and apologized, rewrote the paper, and explained the whole thing to the class at the next meeting. That class never had a problem with cheating again as far as I know.
This could be applied to CS classes if there are student's with identical programs. Give them high grades and have them each present their solutions to the class separately and they will be forced to admit what they have done as it will become obvious to everyone present.
In my experience, one thing that works is to make sure students care about the work they produce. When they think that the quality and honesty of the work is is important to them, and to others they tend not to cheat.
The prof should mention once in class that there have been cases where homeworks bore a striking similarity and that he hopes everyone will try to get the maximum learning benefit from doing their homework as independently as possible and that he and the T.A.'s have office hours if anyone is having particular problems. Competent students that simply let others crib without learning are not doing the cheater any favors, any more than buying an alcoholic a drink does that person any favors.
Some more ideas:
1. grade the students based on practical, speed tests (not essays or homeworks). What is concept? How would you use it in case? What is the error hidden in lot of code here? 2. grade the students based on my subjective perception of how much each one absorbed. pop quiz everyday, 3 or 4 students a day, noting my remarks on their answers. keep them interested. 3. to smooth 2, throw in some auto-evaluation.
Homework is for *you* to understand how well you've absorbed the material...tests are for the prof to determine how well you've learned and to grade your understanding.
Taking advantage of it:
Here's a radical notion: legalize it.
I'm serious: in the spirit of "pair programming" and "egoless programming", make "cheating" or collaboration permissible. Just point out that the submissions had better not look identical, and make them disclose who they're collaborating with. If you think there are one or two students who are supplying the whole group, cut them out and give then different assignments.
I've worked with this kind of notion both as a student and as a professor, and I'm convinced that it actually leads to overall better learning — as well as letting me relax and not get all het up about it.
1. Accept it. In most classes where there were paper-based assignments (think Math, Physics, etc.) our profs would basically say on the first day of class "I know you're all going to work together on these assignments. Fine. But remember that exams arn't done in groups." and would then point out the fact that assignments were only worth ~10%. Thus, we all learned the best way to work as a team, got everything done, and had good sets of notes for the final. Also had the bonus of having to explain each solution to your friends, so you knew much of it inside out by the time exams came.
2. Expect it. At the start of the semester the prof would announce "I don't care where you get your answers from, as long as you cite and reference them." (mainly for programming and design clases). He'd then give us a list of decent sources for programming information/examples. But then all the questions he'd set would be different enough that you could only copy-and-paste parts of the code most often found. Thus, you learn to see what's been done in the past and not to reinvent the wheel, while at the same time having to work with and understand a stranger's code. Which is exactly what working with any downloaded code (think SDKs) is.
- Assignments were graded only on a completion credit. Every day, he would take questions regarding the previous assignment, so you could learn more about any equations that gave you trouble.
- On the test, every question was either directly taken from the homework, or adapted from the homework. The only way you could do it is if you could do the homework.
- You were required to show work on the test. You could get partial credit depending on how far you got in the problem before you messed up; likewise, whether the answer was correct or not, you'd get no credit if you didn't show your work, since that was part of the instructions.
- Tests were weighted in such a way that you could not pass the course without passing the tests.