Pair Programming Is Beneficial…In The Classroom

Follow us on LinkedIn for our latest data and tips!

Pair Programming Is Beneficial…In The Classroom

Recently, I was reading a series of articles on TechCrunch about the usefulness of pair programming.

Pair programming is a software development technique popularized by the Agile movement. In the world of pair programming, two developers work at a single machine at the same time. One is the driver, the other is the observer (personally, I prefer the term co-pilot, and I’m sure Simon Roberts would agree). Together they write code: one bangs the keys, the other functions as a real-time q/a / complier / sanity-checker.

The TC editorials did a decent job looking at the pros and cons of pair programming on the job. It was interesting to me that many of the pros listed related back to learning. Developers historically (back when I was just a kid) didn’t really like the whole knowledge sharing idea – instead, corporate programming was more centered around a culture of knowledge hoarding. Thankfully, that culture has changed nearly as fast as technology has changed.

I fully agree with Farhan that pair programming, when done properly, can be a great learning vehicle. I also agree that it may not make sense for a developer to do pair programming all of the time, in every situation.

Here’s a dirty little secret that might just shock the development community: Despite the newness of this idea in the programming world, and the debate on TC, pairing as a learning vehicle has existed in corporate training for as long as I can remember. As long as the instructor creates and nurtures a culture of openness and inclusion, pairing happens automatically and people do learn faster.

Over the past eight years we’ve been teaching developers, nearly every single one of our instructor-led training courses has incorporated pair programming in some form or fashion. In some cases, the pairing is forced, due to the lack of equipment in our client’s training rooms. In other cases, the pair occurs naturally, when neighbors ask each other for help.

we have been delivering a number of dedicated classes to mixed-experience teams. Most in the learning world would say this is a bad idea, that you should do experience based learning, or you’ll end up teaching to the most junior people in the room and frustrating those with experience. But, we’ve actually found that if you pair a senior person with a junior person, for the entirety of the course, it actually levels the knowledge playing field. AND (that’s a big “and”), the junior people learn more, with less frustration, than they would have alone. Oh, and those senior people? Well, they actually “deepen” their own knowledge by having to share it with their driver.

So how does this work?

We start off every class by surveying the room, asking people, “How much experience do you have with HTML5?”
As the developers go around the room and share, we identify the experts and the newbies. Then, we pair up an expert with a newbie. The experts are the co-pilots and the newbies are the drivers. Scary, I know. You would never let your kid drive before being ready. But, in the world of programming, learning by mistake is as important as learning by doing correctly. Of course, we ask before pairing. Forcing a pairing with your worst enemy doesn’t really pan out well.

Then it’s off to the races. Since over 60% of the classroom time is focused on creating the top-of-mind, finger-tip-knowledge developers need, there is a lot of opportunity for pairing. But, unless pairing is forced by limited equipment, we don’t use pairing in every lab. For example, when we are doing a simple, five-minute follow-the-bouncy-ball demo type lab, we don’t do pairing. Those labs are focused on the mechanics and not the “how,” so pairing isn’t necessary.

When we get to the open-ended, story-problem, progressive labs, where developers need to solve a real problem with the technology they are learning, we always use pairing. By pairing students for these labs, they not only learn the how, they also get to collaborate on the design, the strategy, the test plan, and of course, the code.

Like pair programming on the job, pair programming in the classroom may not always be the best learning strategy. But when there is a team with mixed experiences, it works out quite well.

If you want to brainstorm the best way to get your mixed-experience teams up to speed on JavaHTML5, or other open source technologies, give me a call at (720) 445-4363.

– Kelby