To Pair Program, Or To Not?

When is pair programming useful and effective? When is it not?Photo by Maxim Tolchinskiy on UnsplashWhat Is Pair Programming?Pair programming is when two (or potentially more) software engineers code a feature together on one machine. There are actuall…


This content originally appeared on Level Up Coding - Medium and was authored by Michael Faber

When is pair programming useful and effective? When is it not?

Photo by Maxim Tolchinskiy on Unsplash

What Is Pair Programming?

Pair programming is when two (or potentially more) software engineers code a feature together on one machine. There are actually many different approaches to pair programming, but the most common involves two roles:

A driver, the software engineer “at the wheel” coding the feature.
A navigator, the software engineer observing.

In most cases, this form of pair programming boils down to one of four different scenarios:

  • Senior software engineer driving, senior software engineer navigating
  • Senior software engineer driving, junior software engineer navigating
  • Junior software engineer driving, senior software engineer navigating
  • Junior software engineer driving, junior software engineer navigating

Many discuss that the driver and navigator switching places is a best practice for pair programming. This practice has its pros and cons, naturally. I’m not going to consider it in this article.

Senior Driver, Senior Navigator

Of the four, this scenario provides the least amount of value. But not none.

I’ve always believed the primary objective with pair programming is learning and not productivity. There’s an old joke about software engineering I’ve heard many times:

Thinking that two software engineers can build a feature together in half as much time is like thinking two women can give birth to a child in four and half months.

This scenario often results in the driver coding the feature no different than they would alone, and the navigator watching in silence without much feedback. Although there is one advantage here. When it comes time for the driver to submit a pull request, the navigator doesn’t really need to take a close look at it because they watched the driver code it up. But to be fair, this is true to some extent for all four of the scenarios.

Senior Driver, Junior Navigator

This scenario is great for freshers. I did quite a bit of this at my first ever software engineering job, an internship. It was always a great learning experience.

It does take time out of the senior software engineer’s day. Answering the questions of the fresher and providing explanations in real time will slow down the development of the feature. They also don’t really get to reap the benefits of a quick pull request merge, because they’ll likely want someone who isn’t a fresher to review it.

Despite this, I believe those in favor of this scenario are smart, long term thinkers. It’s an investment that will pay dividends. The fresher will reach a point where they can work independently much faster than if they were thrown to the wolves.

Junior Driver, Senior Navigator

This is the quintessential pair programming experience. A junior with enough experience that they aren’t uncomfortable driving, and a senior providing them with feedback in real time.

This scenario is great for growing junior software engineers into senior software engineers. When it comes to becoming a senior software engineer, getting feedback from other senior software engineers is an important part of the equation.

Junior Driver, Junior Navigator

The knee jerk reaction might be that this is a waste of time, but some of my favorite pair programming sessions have been this scenario.

When you’re working with a software engineer with a similar amount of experience as you, it’s much easier to “speak the same language.” Senior software engineers are also generally pretty busy, and seen as “expensive” resources. Realistically, they may not always have the time or bandwidth to pair program with a junior.

Also, on a more candid note, this scenario is just fun.

Thank for you reading!


To Pair Program, Or To Not? was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.


This content originally appeared on Level Up Coding - Medium and was authored by Michael Faber


Print Share Comment Cite Upload Translate Updates
APA

Michael Faber | Sciencx (2022-03-24T01:09:06+00:00) To Pair Program, Or To Not?. Retrieved from https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/

MLA
" » To Pair Program, Or To Not?." Michael Faber | Sciencx - Thursday March 24, 2022, https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/
HARVARD
Michael Faber | Sciencx Thursday March 24, 2022 » To Pair Program, Or To Not?., viewed ,<https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/>
VANCOUVER
Michael Faber | Sciencx - » To Pair Program, Or To Not?. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/
CHICAGO
" » To Pair Program, Or To Not?." Michael Faber | Sciencx - Accessed . https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/
IEEE
" » To Pair Program, Or To Not?." Michael Faber | Sciencx [Online]. Available: https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/. [Accessed: ]
rf:citation
» To Pair Program, Or To Not? | Michael Faber | Sciencx | https://www.scien.cx/2022/03/24/to-pair-program-or-to-not/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.