DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Join us tomorrow at 1 PM EST: "3-Step Approach to Comprehensive Runtime Application Security"
Save your seat

Pair Programming for Introverts

Bring value to your team and retain your own sanity.

Dave Farley user avatar by
Dave Farley
·
Nov. 27, 18 · Opinion
Like (3)
Save
Tweet
Share
7.11K Views

Join the DZone community and get the full member experience.

Join For Free

A friend of mine has recently started work at a new company. She asked me if I'd answer a few questions from their dev team, so here is the first in a short series of their questions and my answers...

Q: "Pair programming has been shown to increase quality and reduce overall development time. Nevertheless, some need heads down focused time on a problem. How do you balance this?"

My preference is to strongly encourage teams to adopt the norm that most work will be done working in pairs, but not to make it a rule. I think it right to leave room for people to decide for themselves when it doesn't make sense.

However, you are right. All of the data that I have seen from studies of pair programming say that it produces higher-quality output, and so in the long run, is significantly more efficient in delivering new code. More than that, I know of no better way to encourage collaboration, learning and continual improvement in a team than pair programming.

(Links to some of that research at the end of my blog post "Pair Programming - The Most Extreme XP Practice")

So it is strongly in a team's interest to adopt and encourage pair programming as the norm. It is not good enough to reject it because some people don't like it. That would be like mountain rescue teams rejecting the use of ropes because it is annoying to carry them up the hill. Some things have value even if they take some work.

For me, this means that it is worth some effort, maybe even significant effort, for a team to adopt, learn, and make pair programming a fundamental part of their development culture.

My experience has been that most people, before they have experienced it, are nervous of pairing.

In part, I think that this is a cultural thing: we "program" people to imagine software development as a lonely introspective act. I don't think that good software development is really like that. It is, at its heart, a process of learning.

We learn best when we can try out new ideas and quickly discard the bad ones. One way to test ideas is to bounce them off another person. So pair programming provides us with a mechanism to quickly and cheaply exercise ideas and weed out some of the bad ones.

There are also some individuals who will always find pair programming stressful.

If I am honest, I believe that these individuals have a more limited value to the team. They may have value, but that value can't be as much as someone of similar skill who learns faster and teaches more.

Introverted people are more sensitive to stimulation than others, and so need more quiet time to reduce the cognitive clutter. I am one of these people. I need, periodically, to be on my own to organize my thoughts. This doesn't mean that people like this can't take part in pair programming; it does mean that you have to give them some space, some of the time.

So, my idea of "optimal" is to do most, nearly all, development work in pairs but allow humans to be human. If someone needs time to form their thoughts, or learn some tricky concept alone, or just needs some quiet time to recharge for a bit, give them that time.

There is another important aspect to this. There is some skill to pair programming. It takes time to learn some of the social aspects. For example, one very common behavior that I see, in newbies, is for my pair, when I am typing, telling me letter-by-letter when I make a typo or what the instruction is. They are trying to be helpful, but they are not.

Watch your own typing for a bit. If you are anything like me, then your typing will progress forwards and backwards as you make little mistakes and then correct them all of the time. When this happens you know, as you type, that you made a mistake. Most errors you correct immediately. Someone telling you at this point, actually slows you down. It interrupts the flow of your thinking — and it is irritating.

So when you are pairing, and you are not typing, give people a chance to spot, and correct, their own mistakes. Only mention a typo when the typist has moved on and clearly missed it. Only mention the correct use of a language construct or API call if the typist is clearly stuck. Otherwise, keep quiet!

The classic description of the roles in pair programming is the "Driver" (the person who is typing) and "Navigator" (the person who is not). This is a bit crude, but close. If you aren't typing your focus should be on the direction of the design rather than the typing.

The other important aspect of pair programming as a learning activity is to regularly rotate the pairs. Change pairs often, don't allow pairs to become stale. My preference is to change pairs every day.

This sounds extreme to some people. It means that nearly everyone works on nearly everything that the team produces over the period of a week or two. It means that you get to see different people's styles of working (and pairing) and learn from them. It means that you get to work with the person on the team that you find trickiest to pair with and with the person that you enjoy working with the most, on a regular basis.

Pairing means that you are working in very close proximity to other people. Think of your pair as a team, you have shared goals and will succeed, or fail, together. Be considerate, be collaborative, be kind!

If you get this kind of stuff right, then the barriers to pair programming begin to reduce. Even the introverts on your team will not only take part, but will benefit from it.

Pair programming takes time to adjust to. This is not something that you can try for a day or two. It takes a while for a team to get really good at it, so allow yourselves the time, don't give up too soon.

Software development teams

Published at DZone with permission of Dave Farley, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The Top 3 Challenges Facing Engineering Leaders Today—And How to Overcome Them
  • Simulate Network Latency and Packet Drop In Linux
  • Real-Time Stream Processing With Hazelcast and StreamNative
  • Mr. Over, the Engineer [Comic]

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: