Appropriate Collaboration

Humans do not stand alone. In programming, as in other arts, we do better work and learn more when we communicate and cooperate. Sometimes, however, people copy the work of others as a way to avoid their own work; such plagiarism is unhelpful and unethical. The other extreme, however, leaves you working without the benefit of other people. Finding the right middle path is one of the things students must learn in their work.

Getting and giving help

Not acceptable: “Can I see your program?”

Not acceptable: “Here is my program, check out how I did it”

In a programming class, you are asked to program in order to practice writing and debugging code. A working final program is actually not the goal—the process itself is. Skipping ahead to the answer (especially with copy and paste) robs the learner of practice at breaking down a problem and building a solution in small, testable steps. Learning to build your way to a solution without a step-by-step guide to follow is a critical part of your CS skill set—it is arguably the single most important skill to develop in the CS sequence.

In a class setting, the teacher occupies a privileged position, as do teaching assistants, tutors, and other such helpers. You can share your code with them and go over it in detail without worrying about plagiarism. Another student who will be graded separately for their own work should not be looking at your code, and vice versa.

So how can you collaborate appropriately with other students?

Talk general strategy

As a question: “Hey, I know I need to chop up this string; what functions can I use to do that?”

While giving advice: “I found I had to use two loops to solve that problem.”

Share examples from the class, book, or other material

“Oh, you should check chapter 5.8—it shows how to do that.”

“I used the StructSample project as a starting point for this project.”

Create your own example

Make up examples using snippets of code not directly related to the assignment. If someone asks “How do you know if string.find() can't find what you are looking for?”, you might answer:

It returns the special value string::npos, like this:

string foo = "something";
if (foo.find("q") == string::npos)
  // it is not there

Share a diagnostic message

When seeking help with something the compiler is telling you, it is appropriate to include the error or warning message, along with a description of what that part of your code is trying to do or how you have explored the error so far. For example:

main.cpp:9:1: warning: control reaches end of non-void function

That line seems to be the closing curly bracket for one of my functions, and I'm not sure how that part could be wrong. I do have some tests for the function and it's returning the right thing for them. Should I ignore this warning?

Isolate a snippet

If you are debugging a syntax error on one line of code, it is reasonable to share that line of code by itself. For example:

Why does this line of code give me an error that says “expression is not assignable”?

4 = x;

Answer with a question

When offering help, think about what you can say that will actually be helpful. Imagine watching someone struggle to solve a puzzle or win a game that you have already solved or won. If you tell them nothing, you have not helped, but if you give them spoilers, you have robbed them of that problem. Can you ask them a question that leads in the right direction?

Coming up with good leading questions is difficult, and it is a skill like any other that must be practiced for you to become good at it. Play it safe and stay on the side of not saying enough, rather than saying too much.

A useful book on this subject is George Pólya's How to Solve It, which is primarily about asking questions that guide someone (perhaps yourself) through solving a problem, in a way that allows them to construct their own solution and learn from what they have done.

Assisted debugging

Sometimes, the only way to see what is wrong with some code is to see the whole system and debug it in a live format (e.g. face-to-face or screen sharing). This is a dangerous gray area. If done appropriately, it is acceptable. But it very easily can turn into inappropriate collaboration.

To be acceptable, it must involve live interaction. This is because the focus should be on the debugging process, not on what code to write. The individual doing the assisting should be helping the code author find the source of a bug. The communication should be about what is known about the state of the program and what it might be smart to check on, or how to do that using the debugger or print statements. The helper should not be finding the bugs or telling the author what code to write to fix them.

Asynchronously, it is too hard to keep the focus on that process. The “help” invariably ends up focused on “here is your problem” or “here is how to fix it”.

Debugging your own code

As a person who is asking for help, focus on things like:

• Getting help understanding what your code is really doing, i.e. using the debugger and print statements and then examining the evidence they provide to understand your code.
• Identifying small steps to take next and how to check that work.

You should not be getting help on actually writing new code. If you end up submitting code you can not clearly explain and could not recreate independently, that qualifies as academic dishonesty.

Also, beware of how your code will influence the person you are allowing to see it. If they plagiarize by copying from you, you will also be held responsible.

Guiding someone else who is debugging

If you are trying to help someone debug their code, guide them through their own process of tracking down what is wrong rather than telling them where it is or how to fix it. If you can't guide someone to a solution by pointing out things you are observing and then using the general strategies above, it probably means the person you are helping has bitten off too much at once. Encourage them to backtrack and focus on a smaller, simpler chunk of work—for example, to find the first line of code that goes wrong.

Collaborating in this context is difficult to get right, and if you don't feel confident in your ability to know or follow acceptable standards while working in this way, it is safest to stick to the strategies mentioned above that do not involve one person actually looking at another person's code, or to ask for help from a privileged person such as the teacher or official tutor.

Final advice

In the end, collaboration is a major theme of computing—after all, what is programming, other than explaining to a computer how to solve a problem, and leveraging its help in turn? The practice of talking about how to find a solution, without revealing (or perhaps not even knowing) what that solution is, will make you a better computing scientist. When in doubt, ask for help!

(You are allowed to ask for help about how to get and give help!)