Like in any subject, academic dishonesty by students exists in coding/programming too. Computer Science (CS) take home assignments in the IB program typically tend to be, for the most part, code fragments that students need to attempt and submit. In my years teaching CS, I have encountered several instances where students have copied code from someone else (either from within the class or from an external source, like the web) and passed it off as their own. One of the biggest tells for such events is the nature of the solution itself. A student who I see clearly struggling in the course or having difficulty with a concept, can raise a red flag depending on the approach the solution produced has taken. But it requires engaging with the student to clarify whether or not the code is his/her own. If the code is original then there is no room for confusion by the creator about both what works/doesn’t and why. So if I have noticed a red flag then the first step has always been a conversation to clarify my hunch.
The reasons behind the why a student would plagiarize code are pretty similar to that of any other subject area – lack of ability, high stress with grades/performance, pressure from external sources to perform well in the subject, weak time management or organizational skills, wanting the solution to do more than what it is doing etc. The list is long. To address these issues I have tried a few strategies that have worked well. This post is about highlighting some of them.
Establish expectations on day 1. Repeat.
The very first time you meet a CS class (either a new group or a returning one) take time to go over the ethical guidelines of the subject. Highlight the school’s policy on plagiarism and, if possible, get the curriculum/IB coordinator to come into the classroom and have a few words with the group to further cement the point that the school has 0 tolerance with such behavior. This meeting can also clarify misconceptions students may have regarding what does and does not constitute plagiarism in coding. The points covered in this meeting should be often revisited, put somewhere public and constantly referred to during the course. It helps establish a standard of expected quality.
Involve the librarian
The other strong strategy that I have used is getting librarian’s to come into the class. They have usually come in to talk about Extended Essays in CS but have often also dug up research to help students get their coding citations in order. This clarity of protocol has helped get rid of any assumptions or misunderstandings students may have about what using borrowed code means.
Remove stress creating agents.
One of the strategies that I have found effective is removing the focus from grades (which is often a major stress maker) and placing it on the process and feedback loops instead. This is tricky, I know, since programs like the IB require and work towards a grade at the end of it. But despite conventional requirements, setting up a learning environment where focus is completely on every piece of work/contribution the student does helps reduce stress.
One of the strategies that I have found effective is removing the focus from grades (which is often a major stress maker) and placing it on the process and feedback loops instead. This is tricky, I know, since programs like the IB require a grade at the end of it. But despite the traditional requirements, setting up a learning environment where focus is completely on every piece of work/contribution the student does helps reduce stress.
The other powerful strategy has been getting them to work in pairs. Peer coding ensures that a student does not feel like a warrior in the dark all alone. They have another person to rely on, interact with, discuss ideas, clarify doubts, express fears and even get creative. Two heads are definitely better than one! So the more support structures a class can provide the lesser the chances that the student is looking elsewhere for it.
Find ways to acknowledge well-researched/cited/used alien code
Being able to read someone else’s code and using it appropriately to make sure it works also takes a certain level of expertise. Often times the code found online may not be well documented or have clear variables or even be doing what the student is looking for! So on some occasions I have let the students use and demo alien code as long as :
a. It is adding a non-trivial new feature/quality to the solution.
b. Is well cited and full credit is given to the original creator.
c. Has a clearly defined purpose and rationale for being used.
This strategy has worked in the sense students, in time, realize the futility of doing such a thing and instead start attempting learning more advanced concepts to customize their own solutions. Having students then share and demo the code to the entire class has made for some good learning activities.
Read a developer’s tweet recently that said “a poor communicator cannot be a good developer”. This is true on so many levels. Internal documentation (via comments within the code and the messages that are printed during run time) are just as important as a reflection piece explaining why something was done a certain way.
Make assignments interesting, purposeful.
There is a school of thought which is against homework. It is a point I completely understand and it embodies an approach I have used several times. Given the rigor of the IB curriculum though, well spaced formatives ensure that continued in-class and out-of-class knowledge testing is taking place. I have relied more on what I see, read, hear in the student’s work in the classroom. So: if a take home assignment is to be given then it need not be uninteresting. If the assignment is built around something concrete, real and contextual, the motivation levels to attempt and complete it rises. For instance, instead of assigning work that merely asks them to use a couple of looping structures how about have them design a a program that accepts some numbers and creates a unique password key based on it? This could be extended to an interactive solution which they could even share with peers to use in real life!
Finally, talk about it. As often as possible.
Academic honesty with coding isn’t something that should be addressed only when there is a problem. In our classroom discussions we have talked about companies stealing code from one another when creating a product, engineers passing off work that isn’t their own and the ethical aspects of computing in general. Students love to engage with these sorts of discussions. So find ways to constantly talk about the ethical aspects of CS so that the student grows an appreciation for the craft.
Further recommended reading
“Plagiarism and Programming: How to Code Without Plagiarizing”