Gamification and GitHub

While working on Author Intrusion, there were a few blog posts that I wanted to write about, but didn't. The main reason, like writing, is that I work very well with single-focus tasks (multi-tasking is the mind killer).

One of the biggest was something I noticed about GitHub. The site itself is fantastic and I love what I can do with it. Actually, my concern with GitHub is this:

gamification

This is the bottom of most profile pages, such as mine. It lists the commits that I've done while working on Author Intrusion and supporting libraries. It lists how much I've been doing on the site, including checking in code, writing comments and issues, and a whole bevy of things.

My concern with it is the behavior it encourages.

Gamification

Gamification is the process of putting game mechanics on things outside of games. The numbers on the profile pages are an example of that, effectively a score. The more commits, the higher the score. The more days I work without break improves another score. If I kept a steady pace of commits, the bars would turn into a tapestry of different shades of colors.

This is used in a lot of places. Stack Overflow, MSDN, and a number of sites give points for posting questions and answers. You have karma on websites, badges for actions, and social connections (Twitter, LinkedIn).

Scores

In most cases, gamification is represented by a score, a number. In writing, I occasionally get hung up on the number of words I write, which is also a score. Yeah, I hit two million words of finished stories and novels, but that doesn't mean they are "good" words.

My commits on GitHub are another score. An incomplete one at that because they only list commits along the master (main branch). This is another case of using gamification to encourage behavior. If it doesn't happen on the master branch, then it didn't happen. So, to get that score, the encouraged behavior is pretty obvious: commit on master.

Commits

If you go to this commit list, you'll see a rapid fire set of commits.

commits

This is how I work. I finish a train of thought and commit the change. The comments are usually poor, a single line for context and nothing more. There are also a lot of commits that basically are churn, me trying something out, reversing part of it, trivial changes for formatting, and even just meandering through some completely unrelated code to fix a minor bug.

Good work

If I put this on the master branch, those thousand or more commits I did in a single month would give me a higher "score" and it would show up on my page. I could fill up those colored squares easily.

The problem is that these aren't good commits. They get me to where I need to be and they are critical. But, they also are the result of frantic writing and exploration instead of what I would consider solid code. The end result might be, but not the intermediate steps.

It also means that if I put that month of commits into the master branch, there are a thousand commits that will become just noise. A year later, I won't care that I removed C5 over three commits or that it took me five to figure out the cross-platform IoC container. I don't need to know that I renamed files at least five times until I found something that felt right. And, it sure doesn't really matter that I committed my work because EDM needed his diaper changed.

Useful history

We switched over to Git at work. One of the things that we sat down was to talk about merging commits. In specific, how to handle developers like me (who commit almost every hour) along with those who only commit once in a few days or even just a single commit at the end. We decided to go with squash commits, which takes all of the commits in a branch and collapses them down into one. This let us have one good history comment without all the extra cruft that will only add noise.

For my projects, I'm going to the same way. For most of the Author Intrusion development, I threw everything into the drem-0.1.0 branch. That is the link above and has the commit every hour and a thousand useless commits. My commit into the master branch (the one I get scored on) is a single commit with (eventually) a good, useful commit message.

The advantage is, in five years, I will have a lot less useless noise to drudge through when I try to figure out things. And, hopefully, that will make it easier to work with as I continue to work on this and the other projects.

Driving behavior

The hardest part is that score. It's a number that I know how to make higher, but it won't help anyone if I try to bump it up. So, I'm working on ignoring it. Just like I struggle not to let my word output mean anything (at all).

Gamification is about encouraging behavior. But, it is really easy to obsess about the score (get the highest karma, the largest number of badges, the most people in your network, the largest posts) and miss the entire point. If I wanted a thousand tweets, I could, but they aren't good ones. If I'm only trying to get good ones, then that number is meaningless. Same with words, stories, commits, and everything else.

Metadata

Categories: