4 Group Work
Some of your assignments this semester require you to work in groups. These are marked with a + on the assignments page. (Note: We have not yet determined all the group assignments; in particular, as of now we do not yet have any peer-review for the programming tasks. Depending on how the semester progresses, we might add one of those.)
For these, you are required to work with a partner: use the Piazza posting for this. If you can’t find a partner by the deadline, we will assign you one. If we have an odd number of students, we will make one three-person group.
You take shared responsibility for everything you turn in. Only one of you turns in the work, so make sure you agree beforehand who that will be.
4.1 For Mystery Languages
It’s important for you to initially try the mystery language assignment alone and get a sense of the languages for yourself. Create a best-effort classifier.
Once you and your partners have each done that, share and discuss them. We have found that doing things in this order is very instructional, because different people sometimes bring a very different perspective to how the languages differ. If you haven’t tried to tell them apart yourself, you can only “participate” passively in the discussion: i.e., that isn’t real participation. But if you come with an active model in your head, you will both contribute and learn much more.
Ultimately, you will produce a single classifier for the whole group. You should then work together on formulating the crispest possible description of the characteristics of the languages.
4.2 Peer Review
In industry, it is common to peer review code: that is, you present your code to other programmers, who critique it on design, correctness, structure, efficiency, and so on. In some organizations, peer-review is required before any code can be formally committed to the code base. These principles aren’t limited to industry: the benefits of peer-review are an argument for open source software, and for demands by security experts to make sources public. Finally, just about every programmer has had a friend come over and look at their code and provide feedback.
4.2.1 Reviewing Examples
“Code”, in the sense of the executable part of the program, isn’t
the only artifact available to review. Many other parts, ranging from
design documents to data files, are also worthy of inspection. In this
class, we will emphasize the review of another important part of
programs: its examples (test cases for the interfaces defined in the
problem statement—
These examples can’t refer to implementation details, which may vary widely.
While people can reasonably disagree about implementation details, there ought to be much less difference of opinion about the expected behavior of the interfaces defined in the problem.
They are concrete. Therefore, they are often more accessible and easier to grasp.
They can usually be understood in isolation from each other. You can understand some without understanding them all, whereas different parts of source code are usually more tightly interlinked.
They might point to weaknesses in your own understanding of a problem!
As a reviewer, you will typically be given three submissions to review. We have found this number to strike a good balance between effort and exposure to a diversity of thinking about the problem.
4.2.2 The “Sweep”
Over time, especially when one assignment builds on another, the set of examples can grow quite large. Reviewing these becomes onerous to other students. They might also miss problems that you would have liked to hear about.
We have successfully tested a simple alternative. Instead of submitting an entire test suite, we will let you submit only a sweep (a term inspired by archeology and geology). The sweep is a set of 5 to at most 10 examples that are meant to be representative of the problem. That is, the sweep asks you to put your “best foot forward” rather than just dumping every example you can think of and forcing your reviewers to sort them out. Be pithy, not prolix.
Naturally, when limited to a sweep, you may no longer be able to cover the entire space of inputs and outputs. You should instead focus on a handful of standard ones and the ones that illustrate interesting corner cases. Sometimes it helps to add a comment to explain why you think a particular example is interesting (or present in your sweep).
4.2.3 Timeline
Performing peer-review after an assignment has been submitted is a little like performing peer-review after a system has shipped: not only useless, but also frustrating when you do find a mistake or a way to make things better. Instead, therefore, we’re asking you to perform peer-review while an assignment is in progress.
To enable this, we want everyone to submit their examples within 48 hours of the assignment being published. Submissions will be assigned to reviewers as quickly as possible. Reviewers, in turn, must submit their reviews ideally within 24 hours. This way, both the reviewers and the authors will receive material with enough time to actually benefit from reading it.
4.2.4 Copying the Work of Others
Once you’ve seen someone else’s excellent test case, you may find it
hard to resist copying it. That’s okay—