Homework 8.0

Code review (in class!)

Please submit homeworks via the new submission page.

In class on Wednesday, April 26th, and Monday, May 1st, we’ll be doing code review of your HW07 submissions. Sign-up sheets went around in class on Monday, April 24th. (Please contact me immediately if you didn’t sign up—you’re presenting on Wednesday!)

Please note that code review is functioning as a homework, with equal weight compared to the other seven homeworks and four worksheets.

Don’t panic: you don’t need to be completely done in order to present. In fact, part of your presentation should include something that you want help on, i.e., something that needs to be improved.

Presenter’s guide

You’ll have (at most) 15 minutes to present on your code, inclusive of questions and discussion. I’d like you to cover the following topics:

  • Your AST. What choices did you make, and why?
  • Your type checker. Why should we believe it’s correct?
  • One thing you think you did particularly well. It can be big (clever way of defining your parser) or small (a nice Makefile).
  • One thing you think didn’t work well. It can be a bug you’re still trying to fix, or it can be some code that comes out awkward no matter how many times you refactor.

The number one thing to remember is: no one else has seen this code before, but everyone is familiar with the lambda calculus. Having examples at the ready (to run in GHCi, maybe?) will make your presentation much more pleasant to the audience and helpful to you.

Reviewer’s guide

I expect the class to participate in the review: ask questions and offer constructive criticism. Be the reviewer you would like to have: patient, thoughtful, insightful, helpful, and non-judgmental. Don’t offer suggestions until asked; ask questions because you want the answer.

Evaluation

Your grade on this homework will mostly come from your presentation (~75%), but also from your critique (~25%).

Presentation rubric

A good presentation has the following qualities:

  • It doesn’t go over 15 minutes, including questions.
  • It covers all four topics above.
  • The presentation is clearly structured and easy to understand.

I expect your presentations to have at least two of the above qualities. Less good presentations will have only one of them. Presentations that fail all three counts will receive no credit.

A tip: the surest way to lose your audience’s sympathy is to go over time. Do not take more than 15 minutes. You should aim for taking less than 15 minutes—say, 10 or 12.

Critique rubric

A good critique helps the rest of the audience understand the code while also helping the presenter see solutions and alternatives. Your participation can take many forms: asking clarifying questions, offering alternative understandings when presenters or questioners have trouble expressing themselves, or offering suggestions to help resolve issues in the code.

A less good critique might point out problems without offering solutions or offer an explanation where none was warranted.

An unacceptable critique is judgmental (“your code is bad”), irrelevant (“your editor is bad”), or otherwise derails the conversation (“your haircut is bad”). I will have zero patience for cruelty or judgmentalness. Classically bad critiques include things like (a) questions that are asked because they’re hard or make the questioner look good, (b) questions that are actually comments, and (c) critiques that require wholesale rewrites.

While I expect everyone to participate in the review, please make sure your voice isn’t the only one in the room that’s heard.