Less than a month ago, I wrapped up the entrance exam for the Ruby Mendicant University online training program.  Around that same time, I created a mailing list and IRC channel for accepted students so that they could keep track of announcements and get to know each other.   What happened next was nothing short of amazing.

In just a few weeks time, we've seen a total of 545 posts to the mailing list, and around 9000 messages passing through IRC.  Far from idle chatter, we've seen self-organization of focus groups ranging from joint code reading sessions to remote pairing via Skype.  This level of participation far exceeds what I've seen on my open source projects, at least in their early stages.  But it also is not a huge surprise to me, as it was baked into RMU's core design from the beginning.

Weaving together the learning and playing phase

I'm not an avid gamer, but I have been known to get sucked in every once in a while when the buzz about a particular game becomes too much for me to ignore.   This happened with the Half-Life 2/Portal series for me, and just last night happened again with a game called inFAMOUS.  These games blend learning into the gameplay, as do most other games I've found really engaging. This approach gives you a steady way to ramp up your skillset without enduring a painfully dull "training program".

RMU started with an initial task designed to get everyone on a level playing field, via our entrance exam.  What is important to notice about the way the exam was designed is that it wasn't meant to be comprehensive, and it wasn't meant to be a knowledge test.  Instead, it provided a problem space to "play" in, and left it up to the participant to decide exactly how to proceed.  But like a good game, it wasn't a free for all, there were subtle environmental constraints to keep folks on track.

Making progress visible and open-ended

Provided with the exam were a set of unit tests, which while not complete, provided a baseline level of expected functionality that must be satisfied.  In addition to these simple tests was a benchmarking script which formed the core task of the exam.   We were working on a memory and performance optimization problem, with the goal being to write a better implementation that would fit nicer in time in space than the provided naive implementation.   Rather than asking folks to optimize something that took up a 100 mb down to 50 mb, I asked them to take a script that ate up 8gb (enough to kill most ordinary machines, or at least severly stress them), and "do the best they could" with knocking down the footprint.  This provided an open ended challenge, in which those who were comparatively newer to attacking these sorts of problems in Ruby could focus on just trying to get that script to run, while the more advanced could try to optimize for as small a footprint as possible without sacrificing the clarity of their implementation.

While it takes some effort to design problems this way, it leads to a much more interesting discussion in the end.  The mixture between the common goal of getting something running and the emergent goals that arise naturally from individual motivations means that each student was able to learn a lot, despite having possibly focused on different aspects of the problem.

Encouraging emergent goals and "Playfulness"

The games I've had the most fun with are the ones where I don't feel rushed to head down a linear path that was predefined for me.  While a certain amount of direction is necessary to maintain the motivation to "complete" something, it should be possible to stop along the way to explore, play around, and persue indvidual goals that come up along the way.  This is another thing that is baked into RMU's design, which we are starting to see unfold now.

Via focus groups, students are getting together to explore topics that are interesting to them.   It's really amazing to see people from all around the world starting to do remote pairing together, and really neat to think that folks are self-organizing adhoc sessions such as last night's code review of RestClient, all without my direct involvement.  I'm thrilled to see folks trying to organize book reading clubs, or talking about how they can work together on contributing open source patches.   Other folks have taken an interest in hacking the RMU system itself, volunteering to build tools to support our operations such as IRC logging, or helping document our progress by writing summaries about our operations.   In each of these activities is the opportunity to learn things that are off the beaten path.

Letting the players help define the game

I have decided to take this all a step farther by setting the requirements for students to have an individual project approved BEFORE their training session starts.  The requirements for this are super open ended: the work needs to be Ruby related, needs to be something that can be discussed with fellow RMU students, and needs to be able to show some meaningful progress in a three week period.

While the sessions will still have some pre-defined problems, I'm going to try to pick topics which will dovetail nicely with what sorts of individual projects our students are working on.  This way, the practice and research they do for RMU will serve a greater goal, and won't just be learning for the sake of learning.  Students are going to be actively encouraged to use their time at RMU to focus on problems that they've been interested in all along, just with the added help of some fellow explorers, along with some guidance from someone who's been playing the game for a while.

RMU students are showing me each day that they can rise to the challenge of active, purposeful engagement.  Even though we haven't started training sessions yet, that evidence makes me feel confident that on the path to the epic win.

Source Materials for Educators

For an entertaining take on emergent goals in gaming, see Matthew Orona's post My Four-Year-Old Son Plays Grand Theft Auto.

Also, see these two TED talks for some inspiring ideas about maintaining engagement throughout problem solving: