Pair Programming

What is Pair Programming?

Pair programming is an agile development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.

Pair Programming What might make it hard?

It’s new for some people
People have different styles/ways of thinking
There has to be more communication
People have a different idea to what it is and how to do it
Can be hard if both people in the pair lack domain knowledge on the task that they are in
It’s intense
It can be tiring
It requires soft skills that most of the team might not have fully developed

Why we do it?

Sharing knowledge
Maintains momentum
Bouncing ideas
Better code quality
More maintainable code
Less bugs
Easier to find edge cases
Higher velocity

You can think through a problem faster when you think through it with someone. Having a partner keeps you focused on the problem. Your partner gets you through little sticking points where you aren’t sure what to do or where your domain knowledge is lacking. You pause less frequently to do research or look up code syntax, or just generally to be puzzled. Fewer defects means more time spent on creating new features and less time spent fixing bugs!

Less stressful environment
More job satisfaction
Good for team building
Greater team cohesion
Positive discussions about possible issues
Reduces “Bus factor”

“Bus factor” is a way of describing how well your team shares knowledge, expertise and code ownership among them. How many of us can substitute for others on the team if someone is missing (i.e., gets hit by a bus)

Collective ownership
Higher degree of learning and people development.

How we pair?

Sit together or setup hangout
Before starting on a task a pair should:
Make sure the task is reasonably well-defined
Read and understand the ticket before starting code.
Come up with possible solutions
Bring solutions to the team and come to an agreement, if needed
Add checklist/tasks breakdown to the ticket

A good pair should:

Ask a lot of questions
Talk a lot

Say what you are about to do, ask for an implementation idea, ask for a better way to solve the problem at hand, bring up alternative ideas, point out possible inputs that the code doesn’t cover, suggest clearer names for variables and subroutines, suggest ways to implement the code in smaller steps, tell the driver that little bit of API knowledge that they need right at the moment they need it, etc. Listen a lot, too, of course. When people are pairing well, they are talking back and forth almost non-stop. Here are some common things to say while pairing: “Do you think this is a valid test?”, “Does that look correct to you?”, “What’s next?”, “Trust me” (when it’s easier to write a little code to make your point than to say it out loud)

Care about the task
Rely on your partner, support your partner
Take frequent breaks
Switch within an hour
Be respectful
Sync up frequently
Celebrate the wins
Not hit your partner :D

References:

Books :

Pair Programming Illuminated by Laurie Williams & Robert Kessler