
Ask HN: Opinions on cheating and modern computer science education - thearn4
So it turns out that I&#x27;ll be teaching a pretty typical CS course this coming fall at a local university
as a part-time professor. I have some time to consider how I want to structure the course before I review my plan with the department. So I was hoping to get the HN community&#x27;s take on two things that I am having a hard time balancing in my plan:<p><pre><code>    - Improving learning and modernizing classroom procedures
    - Preventing cheating
</code></pre>
Basically, I&#x27;m interested in the possibility of using Git, Github, and a CI testing service to deliver, collect, and (at least partially) grade assignments via the most commonly used VCS workflow used by projects hosted on the platform. That is: everyone forks, pulls down, pushes up upon completion, submits PR for testing&#x2F;review.<p>Overall I like the idea because it would expose them to these basic workflow &amp; development lifecycle concepts early. Later, if they take well to it, I would like to explore creating assignments that are multi-stage and legitimately collaborative between me and them (perhaps organized into small groups). I think there is a lot of potential for learning there. And the platform removes a lot of the tedious parts of the process on my end.<p>But, there is a pretty big catch to running a course my preferred way though: other students will see each other&#x27;s pull requests (ie. their completed assignments). In the minds of most faculty, the concern is that this would promote cheating. Academic integrity is something institutions need to protect to ensure the future value of their degree offerings, and enforcing individual assessments of all learning objectives is the way used to achieve that.<p>The on-again-off-again professor in me agrees with that, but the working software engineer in me is a lot less sure.<p>Any thoughts on this from the software professional side of the tracks? I&#x27;m asking the same to other professors that I know as well. I&#x27;m interesting in contrasting the two perspectives.
======
brudgers
To _me_ , CI and distributed version control and such and their tooling are
more in the realm of engineering practice in the domain of computer science.
The cryptographic hashing and merkle trees and scheduling algorithms that
underly them are more the domain of CS.

Requiring students to have full fledged competence in using those tools seems
way outside the bounds of most CS courses other than a practicum that is
focused on _introducing_ those things and again that seems more the realm of
engineering than computer science unless the department has settled on a
curriculum that integrates such tooling.

Otherwise, the risk that you're only teaching to a portion of the class is
perhaps greater than the benefits that come from tossing everyone into the
deep end. The idea that students entering a computer science curriculum ought
to have professional competence as developers is a recent development and seen
by some people as a problem.

Anyway, professors should be professorial and if that's at odds with the
working software engineer hat, take the hat off.

Good luck.

------
bigblind
What you can do, is create a repo that contains the explanation for a task,
maybe some boilerplate, and some tests that will be run by travisCI or
something similar. When students submit a pull request, the tests will
automatically be run, so there you have your automatic grading part. CI can do
more than tests though. You could also check for code style, and complexity
using several tools.

Regarding cheating, maybe MOSS is useful:
[https://theory.stanford.edu/~aiken/moss/](https://theory.stanford.edu/~aiken/moss/)

