Unlocking Success with Pair Programming: Benefits and Best Practices

It takes many companies years to establish the best way to make internships fulfilling and beneficial to both the interns and to the companies for which they work. And Palantir is no exception. In the summer of 2012, I served as the mentor for our intern, Kelsey Bentham, who was studying Computer Science at Mt. Holyoke College in Massachusetts.

Kelsey was the first technical intern Palantir had in a few years, and, at that time, our process for guiding an intern's development needed some formalizing. Palantir values immersive internship experiences. So two of our directors, Colleen Carroll and Ken Rickard, set a top-level goal of full team integration by the end of the summer. As such, we made sure she participated in daily project meetings and took responsibility for completing tasks.

Prior to Kelsey's start, I determined that the discipline and cohesion associated with pair programming made it the best path for moving her toward the goal of team integration. In pair programming, two developers work at one computer and talk through their work while one of them types on the keyboard. This process allows the developers to share skills and quickly learn from each other.

Over the course of the summer, I worked with Kelsey closely and frequently in this capacity. Together, we worked on drupal.org patches for various modules and support tasks for existing Palantir projects. In doing so, I experienced firsthand the benefits of pair programming with technical internships and developed guidelines that Palantir would use with future interns and junior developers.

Pair programming accelerates grasp of the big picture

Palantir has been working with the Drupal content management platform since 2006. Among those of us writing code, we have worked with Drupal on average for six years. On the high end we have John Albin Wilkins who registered on Drupal.org eight years ago. With that much history, Palantir's development staff can thoroughly and quickly grasp the big picture of building a Drupal site.

Interns do not come with that depth of experience or shorthand related to Drupal, however, so grasping the big picture takes a great deal of definition and explanation. In particular, tasks require additional explanation of how they fit into the larger picture of a full site. Larry Garfield might define a task that 'exports the blog view to a Feature.' Explaining that reference to Features module to an intern could take all afternoon or it could take two minutes. It's up to the more senior developer in the pair to know how much of the big picture needs an explanation to provide enough context to the task at hand.

Pair programming also means pair planning

As a Computer Science major, Kelsey had plenty of coding experience with languages other than PHP. To ease the transition into this language, we would often talk through the steps needed in a function or series of functions. Kelsey would write these steps as code comments first. When writing test code, this step means describing the actions taken by simplest in a list like this:

• Check that view draft tab is not displaying.
• Check anonymous behavior. Verify access denied.
• Check that view draft tab is not displaying.
• Log in again.
• Set the node to published.

Writing a block of comments in plain English helps to put an intern on equal footing when pair programming. The comments make it easier to see how the steps connect; something more mature programmers will often take for granted or keep in their heads when working independently. With the blueprints for the work to be done plainly on the screen, Kelsey and I could focus more on the language details of PHP necessary to complete the code.

Balance pair programming with personal responsibility

As the summer progressed, our pair programming shifted toward Kelsey working autonomously and asking me for assistance as needed. In these moments, I always looked for ways Kelsey could complete tasks or steps independently. Often, in the process of writing and testing a function, developers will produce a lot of extraneous comments and excessive whitespace.

Once the code is passing tests or otherwise functional, the more senior developer can walk away and allow the junior developer to finish the task. An hour of pair programming followed by five minutes of unaided whitespace fixing, comment clarifying and patch posting goes a long way. It reinforces the idea that developers of any skill level can ask for help when needed and still take responsibility for finishing the task. That feeling of independent completion builds confidence and makes for better developers.

Slowly transitioning from pair programming to autonomous work helped Kelsey achieve the goal we set at the beginning of the summer. She operated as a regular team member on the build of a multilingual Drupal 7 site for the world's leading architecture firm, Skidmore, Owings & Merrill. I am looking forward to going through this process again with more summer interns in a few months; we are accepting applications through February 15th.