Guide to Organizing Pair Programming Events
With Tokyo Rubyist Meetup, I've held a number of pair programming events where developers work together on programming challenges. The great thing about these events is its a great way to get developers immediately communicating with each other. To get an idea, check out a video from my first event.
It amazes me how fast and enthusiastically developers can start working together, even in the case of my event where they don't necessarily share a spoken language (most participants at my event speak some English and some Japanese, but aren't fluent at both).
An introduction to pair programming
Pair programming is a development practice where two developers program together on a single computer. When practiced, pairs produce code with less bugs and better design, and is a great way to share knowledge between developers.
Traditionally there are two roles in pair programming: the driver and the navigator. The driver has control of the keyboard, and focuses on the immediate task of programming. The navigator looks out for tactical errors, such as typos, and strategic errors, such as heading down the wrong path.
In the context of a developer event, if the skill levels of the pair are different, I'd suggest the more novice developer be the driver. This prevents the situation where the expert "takes over", and feverishly codes while the novice gets lost. It's important to remind participants the goal isn't to "win" by being the fastest pair to solve the problem, but rather take their time so they can share knowledge between each other.
Event styles
I've held two kinds of pair programming events: solving programming challenges and a more tutorial-style event on a new technology.
Programming challenges
With a programming challenge event, I'll give the pair a specific problem to work on, but little other guidance. The problems are the kind of thing you'd work on if you were taking a computer science course. If you need some inspiration, here's some sites that have problems you could use:
One big advantage of this kind of event is that it doesn't require any setup on the developer's machine beyond having the language environment itself installed, minimizing the need to troubleshoot installation problems during the event. It also allows pairs to spend more time programming and less time looking at documentation to understand how a library or framework works.
I choose challenges that take a couple of hours for me to solve. This means some less experienced pairs will probably not be able to solve the problem in the allotted time, but I figure that's better than pairs solving too quickly and not having anything to do. I've also tried to find problems that I can break down into stages, so even if a pair can't solve the entire problem, they can get through one of the stages and feel they've accomplished something.
Even though I leave the actual method of solving the problem up to the participants, I've tried to give them a bit of structure to get started with, such as a predefined class with an empty method body and a simple test skeleton set up. Even as an experienced developer, I'm normally working on an application that already has the general layout in place, so figuring out stuff like how to get tests running takes time that would be better spent by pairs on more interesting stuff. Additionally, your test harness can act as a sanity check to make sure the pair has a properly set up development environment.
This may be obvious, but I think it is important that you as the host of the event do the challenges before the actual event. This allows you to gauge the difficulty and time required to complete the problems, and will make it easier for you to guide participants during the pairing session.
Deciding on the challenges, trying them myself, and creating enough documentation takes me about eight hours for a four hour event.
Tutorial on a technology
I tried a more tutorial-style event when I held a collaborative event with the Tokyo iOS Meetup. Giving developers a chance to learn from someone with a different development background helped make it our most attended event to date.
The event involved using both Ruby on Rails and iOS, so we thought having a more scripted event would help the pairs stay on track. We ended up creating the skeleton of an iOS application that talked to a Rails server, and gave the participants a tutorial both for Rails and for iOS.
During the event, we had several participants who had issues with not having XCode or other dependencies installed properly. This is probably inevitable, as even though we asked the participants to set up their machines before hand, some people did not do so either because of procrastination or lack of technical understanding. The good thing about pairing though is not every participant needs to get a development environment working, as both participants should be working on a single machine.
The downside of this event style is it requires a fair amount of preparation. Both me and the iOS Meetup organizer spent about twenty hours each creating the tutorial.
Know your audience
It's important to know who is coming to your event so you can tailor the content towards the participants and create good pairs. As part of the registration for my event, have participants fill in a survey about themselves, asking about their spoken language abilities (very specific to my event), development experience, and relevant technical experience.
Understanding both the participants general level of development experience, and knowledge of the specific technology is important. For instance at my Ruby focused event, someone who has no Ruby experience but works professionally as a developer might be an expert compared to someone with no real development background but who has written a bit on Ruby code.
You can use this information to create pairs for the event.
Creating pairs
As an event organizer, I want my participants to work with people they normally wouldn't get a chance to. As such, I decided it was better for me to assign partners. I created the pairs according to the following guidelines:
- Pair international and Japanese participants
- Pair complete novices with more experienced developers, as two novices together wouldn't be able to make progress
- Pair people of similar skill levels together, as this encourages peer-to-peer communication and both sides can learn from each other
Pairs won't work out perfectly as your audience won't be perfectly balanced. Also, be prepared to shuffle people around during the day of the event as there will be people who registered but don't show up.
During the event itself
I start the event by giving a brief description of what pair programming is, and talk about the format of the event. I emphasize the goal isn't to solve the challenges, but rather to become better at pair programming itself.
I'll then assign pairs going through the list one by one and asking participants to raise their hand when I call it. I also use a projector to display the pair list to avoid any misunderstandings.
After that, I announce the programming challenge and the participants start programming. While the pairs are programming, my role is to help pairs with any problems that come up. I walk around the event and look for pairs that look stuck. If the pair is having trouble because of a misunderstanding about the challenge, I try to clear it up directly. Otherwise, rather than providing specific advice, I try to ask the pair questions to get them talking to each other about how they might solve it.
After an allotted amount of time, I end the challenge and have the participants push their code to github, make a pull request to me, and then have the participants talk about their solution. The goal of this is to let the pairs see how others have approached the same problem and learn new development techniques.
After the event
After the main event, I host a dinner at a nearby restaurant to allow participants to continue discussions. This is also a good chance to get feedback from participants about what worked during the event and what didn't, so you can make the next event even better.