Codewalks consist of presenters and the audience. Each role has responsibilities and expectations and how well you meet yours will be reflected in your grade.

Presenters

Each of the Tsuro project homeworks are due at 10:00pm on Tuesdays. Codewalkers will be announced by the following morning at 10:00am. If you don't get an email by that time, you aren't it. You have 24 hours to put together an introduction to your code, but you may not modify your code itself (ie, what you hand in is what you present). Codewalks will also occur on Tuesdays, when there is no assignment due. You will get a similar notification but on Monday; the code that you will be grade on will be the code in the repo on Sunday night at 10pm.

Each codewalk'd repo is expected to have a Makefile at the toplevel such that make test runs the test suite on the tlab machines.

For a code walk, please proceed as follows:

1. Give a concise overview of the project's purpose and your solution (contain yourself to only the essentials, thinking about the context other students will need to be able to start reading code as quickly as possible).
2. Explain the overall organization of your program. Here are some pieces to consider that, depending on the assignment you're presenting, may or may not make sense:
   1. a UML class diagram (plus explanations) of the major pieces, their components, and their inter-connections;
   2. an informal diagram that explains the major interactions during a program execution.
   3. a picture of the board state of Tsuro and how that is reflected in your data
   In addition, you may have to explain other aspects of the design.
3. Present the classes and methods in a top-down fashion (even if you designed bottom up). Refine as requested. Be prepared to explain your code organization, why it matches or doesn't match your design.

In general, be prepared to figure out in real time how changes to your information/data specification are translated into changes in your program organization.

For your codewalk, we will give you two grades from 1-5. The first number will reflect our opinion of how effective a learning experience for the rest of the class your codewalk was (holding you to account only for things in your control). For example, digging into how your code is flawed and how suggested fixes from the audience will make improvements that others have not considered is very valuable. Hiding mistakes and defensiveness is not valuable.

For your code, we will read the code you are to present and grade it, also on a scale of 1-5. We will not be looking (very much) for completeness of the code. Instead we will focus on the structure of the code, how easy it is to read, and how well tested it is. That said, if you hand in one 10 line helper function that's beautiful and well tested, you'll still get a bad grade. There does need to be enough of the functionality to stretch you. That said, do not expect you can complete every assignment in a single week. The code for some weeks is easier than for others; expect to work on multiple assignments each week and to make your own priorities for where to spend your time. Roughly speaking, if you are spending less than 10 hours per week, you are probably not putting enough time in and if you are spending more than 20 you are certainly putting in too much time.

The delta between the first and second code grades is as important as the grade itself. In other words, what we care about is that you demonstrate you learned something; software development takes a lifetime to learn and we aim to make your grade reflect your trajectory, not your position.

Audience members

Audience members are expected to engage with the presentation, primarily with the goal of understanding the code. Secondarily, a fresh set of eyes on some code may lead to improvements to the code, but be aware that you know a lot less about the code than the presenters so ideas and suggestions you have probably have already been thought through by the authors of the code.

During the presentation, there is a natural tendency to offer comments that are simply syntactic, e.g., “Change that x=x+1 to x++” or that start the conversation down unhelpful paths, e.g., “In my code I solved that problem [....comments not about the code we are seeing....]. Why didn't you do it that way?” These kinds of comments are not welcome.

Comments that implicit admit your ignorance, however, are welcome. For example, saying “I don't understand what happens when [... some interesting situation...]” or “What does line 76 do? I don't understand those constructs in your programming language.” Bear two things in mind here: your goal here is to get better at reading code and you are never the only one that is confused.

You will be graded on your comments. Be sure that you contribute to the conversation and yet avoid monopolizing the conversation. Your grade will be influenced by our judgment of how well you strike that balance. If you prefer to make comments outside of the context of class, that is welcome and you should use GitHub to do that. Be aware that we expect more substantial comments if you use this route, as you will have more time to think about the code. If you wish us to consider comments you make in this fashion, be sure to put @rfindler and @chrdimo in your comment / pull request, so we know to look at it and evaluate it.

We expect to produce a small amount of information about your participation score after each codewalk, via canvas. Look there to get our assessment of your participation and to incorporate feedback into future codewalks. Expect your grade to be fluid and not a simple average of those grades; as with the code, we want to see that you are improving across the quarter and thus early grades are worth less than later ones.