From: Evan Martin (martine_at_danga.com)
Date: Mon Jan 26 2004 - 09:24:22 PST
I always thought the writeup part of CS assignments were lame, but now
that I'm grading I see how vital they are. Please keep in mind that I'm
spending hours and hours reading through each assignment and that after
six hours they all look more or less the same. Forcing me to read and
understand your code well takes significantly more time and effort than
reading a clear and thorough writeup, and it makes me cranky. :)
So:
- If your writeup explains your reasoning well, I won't take off
as many points if you write the "wrong" solution. A few groups wrote
in their writeup that they considered option (A) but decided on (B),
and even though I was looking to see (A) I can see that they
understood it.
- When your writeup is good, I'm easier on the grading of the code in
general.
- If your writeup just restates your code ("first, we're going to
unpack the packet. then we're going to check if it's nil, and if so,
print out a warning message and return.") then it's not very useful;
I could just read your code instead!
For example, if your writeup was this:
To prevent needless flooding, we kept an array indexed by node address
that stored the last time and sequence number we heard from that node.
We expired information in that array to prevent it from getting too
large. We also subtracted one from the TTL before reflooding packets
and were sure not to send any TTL=0 packets.
We sent neighbor broadcasts periodically, using a TTL of one
to restrict their reach, and used the "from" parameter on receiving
pings to figure out which neighbors respond.
Then I would have been so happy you would have earned 5 bonus points.
:)
Similarly with the fishnet output. I almost subtracted points for
wasting paper, and I am warning you now that I will in the future.
Not only are 20 pages of packet dumps a waste of paper and ink, they're
also a waste of my time: I can't possibly make sense of them.
Please edit your code so it prints out only useful information. Think
of it like a "proof" for your code: for each debug line you output,
think, "How does this demonstrate my program works?" (And conversely,
be sure to include the information that does prove it.) I should be able
to glance at the output and be able to say, "Oh, they obviously got it
right."
-- Evan Martin martine_at_danga.com http://neugierig.org _______________________________________________ Cse461 mailing list Cse461_at_cs.washington.edu http://mailman.cs.washington.edu/mailman/listinfo/cse461
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 09:24:28 PST