CSE 351: The Hardware/Software Interface
HomeCalendar

Collaboration in CSE 351

Policies
Most of these policies are also covered in the syllabus, but are repeated here for convenience. Keep in mind that the goal of collaboration is to help each other learn, not to finish the assignments in the least amount of effort!

Collaboration is highly encouraged in CSE 351 and you are given the option of completing almost every assignment (except the exams) with one or more collaborators:

For lecture polls, you are highly encouraged to discuss and work through the problems with your neighbor(s). TAs will be available to answer questions or may come talk to you during the work time. However, each individual student is expected to vote in via Ed Lessons in order to earn credit.
For pre-lecture readings and homework (and Lab 0), you are allowed to freely collaborate with any number of your peers, though we recommend groups of no more than 4-5 students. Each individual student must still submit their responses to the appropriate Ed Lesson to earn credit. You do not need to indicate who you collaborated with. We recommend discussing both before submitting your first response as well as after submission, if you did not come to the expected answer.
For labs, one partner will submit to Gradescope and then needs to add the other partner to the submission by clicking the "+ Add Group Member" link. Note that the partnerships apply per submission, so if you resubmit a newer version of the lab later, you will again need to add your partner to the submission.
Each partner will be assessed a late day individually for each day that a homework is submitted late. Late penalties are applied to individual students who exceed the allotted late day tokens (i.e., one partner can have a homework score penalized without it affecting the other partner's score).
You are allowed to switch partners between labs. However, nobody likes a ghost 👻! If you do choose to switch partners between labs, please let your current partner know as early as possible.
Tips and Tricks

Working with a partner does not automatically guarantee a smoother and easier workflow! A common misconception is that working with a partner means that your workload get cut in half. This won't be the case, but that's okay! If each of your workloads ends up at less than what it would have been working individually, then that's a win! The main benefit of working with a partner is the ability to discuss your approach and share code without worrying about violating any academic conduct rules.

For 351, in particular, a common pitfall is having one partner "drive" (e.g., type, compile, submit) all the time. As most students will be using the Linux command line and related tools for the first time in this class, it is very important that both partners have the opportunity to practice these skills. These skills are super important for the future!

Common Approaches

Pair Programming: This is the recommended approach (backed by research!) and means that you'll have two eyes on your code at all times as you work. This does mean that both partners need to be available at the same time, but this still can be accomplished remotely via Zoom screen share, though switching drivers becomes trickier.
Independent Work with Check-ins: The key to this strategy is frequent communication about progress and issues. The communication needs to be of sufficient frequency and quality to gain the benefits of getting two sets of eyes on both of your work and the ability to brainstorm and work through issuestogether. This communication could happen (in order of most to least recommended) via short meetings (in person or via Zoom), via detailed code comments, or via email.
Complete Division of Labor: Unfortunately, this is the most commonly adopted approach by students and also the least effective. You are putting a lot of trust in your partner to complete their part on their own without any help, but, more importantly, you are also voluntarily giving up your chance to look over their code and to understand/learn from their part of the assignment! Each individual student is responsible for the expected learning gains from every assignment in the course and choosing to skip parts will only hurt you for the exams and later on when those skills might be needed.

Collaboration Tools

Version control: You need to make sure that you and your partner are working on the most up-to-date version of your code! While you will use git in many other courses in the CSE curriculum, we won't introduce it in 351. Other ways to manage files include Google Drive, OneDrive, Dropbox, and Box. We don't recommend trying to keep track of emailing files back-and-forth with your partner.
Zoom: Many of us are quite familiar with Zoom at this point, but as a reminder it is a useful application for working together remotely. Along with the ability to share your screen, you can allow your partner to make on-screen annotations as well as remotely control your code editor window.
Whiteboard applications: There are a variety of whiteboard applications available that are useful for drawing and sharing things like memory diagrams. Some applications even support concurrent collaboration such as Google Jamboard. It is useful to be able to save or screenshot your drawings so that you can reference them later.

Best Practices

Establish Expectations Early

Clear and frequent communication is vital to the success of working with your partner. Part of this means establishing expectations early, which might take the form of a short conversation/discussion. Potential topics to discuss include work approach, what your schedules and priorities are for the quarter, approaches that have worked for you in the past, comfort level with topics and tools, submission handling, and late day usage. Remember that you're not trying to impress your partner; being realistic will allow you to formulate a plan that will work for both of you. Expectations do not need to be an exhaustive contract between partners, but having some communication before beginning can alleviate later frustrations and misunderstandings.

Read and Discuss the Spec

The lab specifications for this course can be quite long with lots of information and tools that can be easy to miss. It is recommended to read the specs on your own first, taking notes on key aspects or areas of confusion, and then discuss with your partner. This is useful for checking each other's understanding prior to writing any code and can save time in the long run.

Be Specific in Your Tasks

When establishing tasks for a work session or dividing work among partners, the more specific you can be the better. As opposed to saying your task is to "finish the assignment", try identifying specific functions/files/features you will work on implementing. This can increase efficiency.

Visualize, Visualize, Visualize!

Many of the concepts in this class involve the details that are specifically abstracted/hidden away from the programmer, which can make the moving parts harder to follow. We highly recommend using visualization tools (e.g., pen-and-paper diagrams, simulators, debuggers) to assist you in understanding and following the state of the computer as it performs the desired actions. When working with a partner, these visualizations are useful ways to convey your thoughts and can help illuminate misconceptions or incongruities between your intent and implementation. You will likely be asked to draw these by staff members in office hours, so best to get in the habit!

Check In and Take Breaks

Regardless of the approach you and your partner follow, taking breaks from working can increase your productivity and reduce frustration. With pair programming in particular, checking in with your partner while you work and taking breaks as needed can greatly improve the experience.

Take Notes as You Work

If you are working without your partner present, write down any question or uncertainty that crosses your mind while working on your code so that you don't forget to get it addressed when you next communicate with your partner. This could be on a physical piece of paper, in a digital document, or directly in your code comments (but don't forget to clean up unwanted comments later!).

Share Successes and Failures

Make sure to share both successes and failures that you encounter with your partner so that you both can learn from your individual experiences and can try to avoid running into the same issues in the future.

So instead of just saying "oh, I fixed it," take the time to explain what the problem or misconception was and how you fixed it.
Similarly, if there was a part of your solution that you found clever or interesting, make sure to share your excitement and tips with your partner.
Come to Office Hours Together

We understand that student schedules are extremely busy and that sometimes it is not feasible for both partners to attend the same office hours. However, we find that partners that attend office hours together are more efficiently helped and often come out with deeper understanding.