I guess I'm an Explorer: Bartle's Player Taxonomy Applied to the CS222 Achievement System

I had a student come to office hours this week with many questions, some of which were about the achievement system I am using in CS222. I had explained on the first day of class that the achievements were inspired by trends in video games. Achievements give a student a way to be recognized for doing something special, for doing something they might not otherwise do that is relevant to the course. As of this writing, I have 25 available achievements for the course, including technical, research, community engagement, and social options. A student who seeks an "A" grade will probably complete five or six.

The student in my office acknowledged the video game inspiration, and then he asked, "So I should try to get all of the achievements?" I was a bit surprised at this, but he explained that he is a completionist: he sees achievements as an incentive from game designers to have players try all the different options, and that to have "the full experience" one needs to get all the achievements. I responded that my intention was not to encourage a complete collection, but rather to incentivize diverse behaviors that were worthy of class credit.

He looked a bit puzzled, so I asked if he was familiar with Richard Bartle's Player Taxonomy. He wasn't, so I gave a little background about MUD and then explained some of the types. I told him that the behavior he described was characteristic of an Achiever, but that another type is Explorer, who seek out all the edges of the system...

And he interrupted me, saying, "Oh, so you must be an Explorer."

I paused, a bit dumbfounded. I had never really thought about it before. I'm sure the question, "What type am I?" had passed through my mind when thinking about the taxonomy, but I certainly didn't have a pat answer. As I thought about the design of the achievement system, I got to thinking about my own behavior as a player. I like to go to all the places and see what's there: I don't have to do all the quests, but I like knowing what they are. So, I told him, it would seem that my behavior is indeed characteristic of an Explore. Look at Bartle's original articulation of an Explorer: "Explorers are proud of their knowledge of the game's finer points, especially if new players treat them as founts of all knowledge." Does that sound like any professors you know?

The more I think about this story, it helps me see how Bartle's taxonomy might be useful for thinking about achievements or digital badges. Socializers are easy: I have achievements that connect my students to other students, alumni, and visitors. I think Achievers are just happy to have a system through which they can gain course credit and get an "A". Explorers have the opportunity to seek out specialized knowledge, in design patterns or build systems for example. As for Killers, I'm not sure how they fit in. At first I thought this was the category for students who argue and complain about the system itself, but I don't think that's quite right. Bartle explains their motivation as, "Killers are proud of their reputation and of their oft-practiced fighting skills." These might actually be my cowboy programmers, the ones who are more interested in showing off what they can hammer out themselves  rather than learning new techniques or working on a team.

What do you think: if you compare your player type and your behaviors in school, do you see similar behaviors?

Explaining software craftsmanship with an analogy to music

One of the four essential questions I used for CS222 last year was "What does it mean to practice the craft of software development?" This was inspired by the title of the book we use in the class, Robert C. Martin's Clean Code: A Handbook of Agile Software Craftsmanship. The question is a bit too wordy when what I was really after was getting students to think about craftsmanship. I revised it this year to "What is software craftsmanship?" I had originally avoided the word "craftsmanship" for its genderedness, but I decided to stick with it, secretly hoping that someone might even write about the endemic genderedness in software development.

Walking to campus yesterday for my second day of classes, I was struck by an analogy that I decided to share with my students. I started the class by asking, "Who here plays an instrument?" A little less than half the class raised their hands. Then I asked, "Who is a musician?" Fewer raised their hands. "So, what's the difference?"

I received a great range of answers, which I acknowledged without judging. These included:

• Musicians can compose.
• Musicians can interpret compositions.
• Musicians perform for other people.
• Musicians are part of a culture of musicians.
• Musicians have more skill.
• Musicians spend more time on music.

Then, I posed this rhetorical response, "OK, so what is the difference between a programmer and software craftsman?"

The point was made, I think. We did not dwell on it, but I could see that it planted a potentially useful seed in the students' minds as we begin fifteen weeks of developing new attitudes and practices around software development.

(At the beginning of every semester, I explain to my students what it means to be on time: it means you are seated, attentive, with your laptop and notebook ready. More specifically, if you come in right before the "bell," you're late, because we start on the hour. I often contextualize this policy by explaining that I am a musician, and musicians know that if you're not early, you're late. This always gets some smiles and nods from students who know how this goes. I'm sure this was an inspiration for my coming up with the analogy.)

Revising CS222, Summer 2015 Edition

This Fall, I am teaching two sections of CS222. It is my only teaching obligation, but it also the first time I am teaching multiple sections of the course. My daily planning for the course has been relatively coarse-grained, doing a lot of in-class demonstrations and reacting to student questions. This won't scale well to two classes: I already get confused between what we talked about in different courses, so I know it would be troublesome when teaching two sections of the same course. Hence, I am doing more day-by-day planning than I normally do. This also gives me the opportunity to be more intentional about how we spend our time. There were always a few days in this course where I think, "I talked too much today." By planning out more ahead of time, I hope to spend more time having students actively engaged during class meetings.

The overall rhythm of the semester will be the same, with about three weeks of individual assignments, a two-week project completed in pairs, and a nine-week, three-iteration project completed by small teams. Students will be able to earn achievements during the two-week and nine-week projects, and these achievements will contribute to their grades.

The grading system itself underwent the most significant change. I had been using a system based on grade caps: for example, if you failed to earn satisfactory marks on an assignment, your grade was capped at D, and higher levels of grade were "unlocked" by earning achievements. I think many students enjoyed this challenge, especially as the achievements permitted students to play to their strengths and interests. However, some students—usually those on the bubble between success and failure—would find the system disheartening, especially when they unlocked higher-level grades but did not actually earn them. This was certainly a failure of planning on their part, as no part of the grade was ever hidden or secret, but it also plays to their weakness: their difficulty in planning was exactly what hindered them from succeeding within this system. As a result, I have moved to a more conventional weighted average.

To make this work with achievements, which previously unlocked higher-level grades, I now allow students to earn up to 20 achievement credits that contribute to their final grade. When a student claims an achievement, the claim can be validated in one of three ways: the student can make the claim themselves, they can have a peer validate it, or they can ask me to validate it. These earn one, two, and four credits, respectively, and requests for my validation can only be made after a peer validation is complete. The motivation for this is to encourage students to review each others' work and learn from each other, and also to limit the number of times I have to simply kick submissions back to the students for not having met some requirement.

I am taking a similar approach with assignments. Last semester, students had to earn satisfactory marks on the three assignments in order to unlock grades higher than D. However, I spent a lot of time returning student resubmissions in what felt like students throwing ideas at the wall to see what sticks. That is, it was not clear that the students were doing their due diligence, and this was both frustrating and a waste of time. Now, a student must pass a peer review before a resubmission will be accepted. I tinkered with grade incentives to conduct peer reviews, including punishments for approving low-quality work, but I decided to keep it simple: I am hopeful that positive peer pressure will encourage these evaluations, and there's an achievement to be earned for students who do several such evaluations. If this doesn't work, I can always add more rules and regulations around peer evaluations another semester.

We had been using Mercurial on a locally-hosted Redmine server, the interface to which was a bit awkward but not insurmountable. I like Mercurial, especially its elegant command-line, but I decided to switch to Git for the semester since it is more popular and built in to both Eclipse and IntelliJ IDEA. Unfortunately, the Git interface on Redmine is even worse, and fundamentally, no one cares if you can get around in that interface: it has no extrinsic value. I was approved for an educator's GitHub account, and so we're going to try that instead. I was hoping to get more experience with GitHub this summer, but our summer research project has involved much more paper prototyping and analysis than programming. I will need to tinker with GitHub a bit to figure out the tools and workflow, but I've heard good thing, and I know there's a large community of practice that I can hook into if I need it.

After reading Essential Questions, I realized that my standard FizzBuzz example—which I use to teach TDD—was not very authentic. It's obviously a made-up problem, and while it provides an adequate context for learning the basics of TDD, I started thinking about replacing it with something more interesting. I am going to try instead a simple program that computes how many days a person has been alive, in part because it provides a good opportunity to talk about using libraries effectively. Now that I'm using Java 8, I have access to a sane time library without having to use joda-time. I tried whipping up a sample UI, but there's no date picker in Swing. Turns out there is one in JavaFX, however, and so I figured I may as well make the jump to that UI library. I still barely know JavaFX, but I think we can get by enough to give students the sense of it, so that they can use it in their own projects if they want to.

I have started using IntelliJ IDEA in some of my own work, mostly because it's essentially the new standard IDE for Android development. I thought about using IDEA in CS222 as well, because parts of it are quite nice. However, there's one "missing" feature in IDEA that made me stay with Eclipse, and that's how it makes it very easy to ignore warnings. In Eclipse, compiler warnings are highlighted in the code and in the outline view of a project. Students generally come into the course completely ignoring warnings, but this is a habit I want them to break: I want them to think critically about warnings. I try to get them to realize why warnings are worse than errors, specifically because you can ignore them even though something is wrong.

Those are the major changes in CS222. I think that I have hit a lot of the pain points I wrote about in my end-of-semester reflection. I have also completely revised the course Web site to be a single-page application using Polymer, but I think that's a post for another time.