The floggings will continue until morale improves.

-- Management

Lab and Workshop Procedures

Grading Weights

Minor (say up to 10%) adjustments may be made to the weights, number of assignments, etc. at the teaching staff's discretion.

Success Facilitation Surveys give mutual feedback on how well our teaching and learning processes are working. They happen at random.

Labs are for appearing in person and handing in or working on and handing in your Lab Assignments.

Workshops are a special UR thing, catching on elsewhere. The beneficial changes are of course internal to you, but we also use workshops to let you demonstrate your engagement and enthusiasm. So the grade reflects "participation".

Late Work Penalties

Labs and Projects: -2% per hour late (to Blackboard). That is, if the original maximum grade is M, the maximum possible grade for n hours late is (1-.02n)M. The assignments disappear from BB 48 hours after due date.

If you need an extension due to personal problems, please obtain the permission of the instructor and then email the TAs and cc the instructor with the new arrangements you've agreed to.

Academic Honesty:

Yogi says: "If you can't imitate him, don't copy him!"

This course follows The University Policy on Academic Honesty .

Multiple Submissions

Multiple submissions are allowed (even encouraged), but cause trouble. E.g,later blank hand-ins can mask TA attention from earlier attempts.

  1. Ideally, we grade the most recent complete assignment (.pdf or .zip).
  2. If there is no complete assignment, we look to see what is gradable and grade that (or at worst them).

Grading Workshops

The workshop leader keeps a spreadsheet with a grade for every workshop:

The final point average is used to calculate the participation points for the class, which will count between 5% and 10% of the total grade.

Grading Rubric for Labs, Projects, and WS Quizzes:

  1. TAs are not required to improve your code to make it run. Remove all impure java, such as lines inserted by Eclipse. Make sure your code compiles using just command-line javac to compile and java to run.
  2. POINTS:
    0: Nothing handed in.
  3. 1: Equivalent to D or E: insincere effort (jokes, limericks, apologies, random code...), code doesn't compile, algorithm not understood... If you know it won't compile, state your diagnosis in the README...what's wrong?
  4. : C = 2.25 points : Fair, below average, sub-marginal content. E.g. compiles but reliably crashes at run time: diagnose and explain your problem in the README.
  5. B = 2.55 points: Good to Average, meets expectations.
  6. A = 2.85 points: Exemplary, perfect work: Runs, meets spec "reliably" (maybe some wrong answers, sometimes crashes...). As ever, explaining your problem in README.
  7. - Appended to letter grades to penale bad style (inadequate indentation or comments, bad code organization like a big program in one huge file, ...).
  8. - Likewise to penalize inadequate README. Include your name, adequate assignment identifier. One-sentence descriptions of all .java files, directions for compiling and running (command line arguments, format for input, input file formats, user interaction instructions...) Also any other information or analysis requested in the assignment.
  9. + Added for extra creativity or functionality (explain in README -- don't be modest). An A+ = 3.0 points.

Projects: Grading Code and README

One thing that might be important to emphasize in 172 that people tried to emphasize while I was there, but never thought was important...code quality. It's too easy to write garbage code that meets the specific requirements for a given project. 172 is a perfect time to really push on the fact that bad/ugly code is just as "non-working" as code that doesn't meet the requirements. It's a much more painful lesson to learn after you graduate :-). You know the typical line of how to enforce turning in assignments on time, "In industry if you're late, you lose your job." Well, that's patently false, I'm not sure I've ever met someone that's met a deadline. However, it is true that if you check in ugly, unmaintainable, code that you'll likely be looking for a new job.

-- Jonathan Norwood, URCS Alum

Labwork is normally to be done with a partner (meant to help, can be painful, anyway part of the 172 experience): there can be exceptions, but in any case make sure all contributors to the lab exercises have their names on the handed-in product.

Projects are a fine chance to get together with others to figure out what's wanted, develop strategies and tactics, etc. However, you are not to copy (or allow to be copied) your code or prose. Hand in only your own work, however much remembered and reinterpreted it is. "Helping someone" or begging for help through file-sharing is actually arranging a suicide pact.

Project Extra Credit

Give a clear description of any extensions or special features of your project. This will be used for assigning extra credit. Some extra credit ideas are mentioned in the Scheme, C, and possibly Matlab projects. Extra credit will be considered after making the first cut at letter grades for the course. If you're near the top of your bracket, or the amount of extra work you've done is particularly large, you can expect it to push you up a grade.

From Numbers to Letters

Final letter grades are computed when all grades are in. With luck, we'll get Blackboard to give you an understandable picture of exactly where you stand at any time.

Back to the course home page
Last Change: 09/07/14, CB