CS315 Reflection Addendum: Misunderstanding Version Control as Back-up

I just finished reading the final exam responses from the CS315 Game Programming class that I wrote about yesterday. One of the questions invited the students to write about their understanding of depots, changelists, and workspace mapping in Perforce Helix. A surprisingly large minority of responses equated version control to backing-up files. That is, students said that the main purpose of version control was, essentially, to have a back-up of your project in case you need it. This strikes me as a particularly naïve perspective. In every case, I provided written feedback encouraging the student to think about the project in the depot as being the real one whereas anything that is checked out is just a shadow of that.

I wanted to mention this here on the blog in part because I am getting back into teaching CS222 in the Spring. I have had some hallway conversations with the professor who is assigned to teach the other section, and we've been talking about how to improve students' understanding of version control as a critical piece of contemporary software development workflow. One of my experiences this semester that inspired me to do this was the realization—confirmed in an honest conversation—that the students in my upper-division HCI class were terrified of pull requests. Their experience in CS222 had inadvertantly taught them to avoid contemporary best practices of version control rather than to depend on them. This could be related to the misunderstanding that I saw in these CS315 exams, where students see version control as an awkward back-up system rather than, well, version control.