Questions from the cards from this week

Materials:

Code examples:

• Directory,
• Makefile,
• thrd-posix.c (Posix),
• thrd-posix_100.c,
• 256-colors.sh (bash script),
• thrd-posix_XINU.c,
• thrd-win32.c (Windows threads), and
• openmp.c, and
• Driver.java (Java)

Also: Mid Exam 1: Wednesday, February 21

 
Brylow as Brylow - Photo by Austin Anderson, 2015

Teamwork

Wednesday (Feb. 1) in class, we formed interdisciplinary teams for Project 3 and beyond. There are four related items in this e-mail.

1) When your team submits code, only one member of the team should be responsible for the turnin of each assignment. If you both submit the same assignment, the turnin system treats them as two different submissions, which potentially gums up both our grading system and sets off our academic dishonesty detectors. This gets particularly messy if members of a team submit two different versions. To ensure that this is not misused by teams attempting to "game" the system, if two members of the same team submit different versions of the assignment, the team grade will be the lower of the two submissions.

2) As a matter of professional practice, and in order to ensure that both members of a team get credit for a submission, you should make sure that the most significant file or files for a given assignment contain the names of all contributors in a comment block near the top. For this week's assignment, there is a comment block at the top of system/kprintf.c that says:

     /* Modified by:
     *
     * and
     *
     */

You should manually coordinate turn-taking with your partner for editing these shared files -- it is possible to get your source code in an inconsistent state if two partners are actively editing the same files.

In a week or two, we'll talk in lab about revision control tools for more effective sharing of team code.

3) To reiterate what I said in class, I expect partners to be of differing majors. COSC, COEN, and Biocomputing majors have complementary skill sets coming into this course, and our previous experience has been that cross-major partnerships result in more robust teams. You are welcome to swap partners before we get started, but all swaps must be agreed to by all parties involved, and should maintain the purity of interdisciplinary teams.

4 (Bonus item, anticipating frequently asked questions) What if I'd rather work alone? What if my project partner is a dud? What if my partner drops the course a month from now? etc.

Work in teams. In industry, software professionals rarely work on anything of consequence alone. Working together successfully on a software project is an essential skill for the majors that take this course, and ironically one that some of our brightest students (nerds?) don't often enjoy or excel at. I'm deliberately scaling these assignments around the assumption that there are two pairs of eyes and twice as many person-hours of work available to meet the deadline.

Some project partners will be duds, or, at the very least, poor matches for their partners. Just like in the real world. And just like in the real world, your bosses expect you to make the most of it, to devise successful strategies for working around conflicts, and to concentrate on being the best team player you can be. Team members who don't put in the work generally identify themselves pretty clearly on individual assignments and exams. In short, they will get what is due to them at the annual performance review. That said, it would be dishonest to put a partner's name at the top of a file if that partner actually contributed nothing at all to the assignment.

If your partner drops/flakes out/disappears into a vortex of slackitude: Don't panic. Let me know as soon as you know. We will combine orphans into workable teams as needed.

-Dr. D

Assignments

Coming assignments