Pair Programming | Arvin Bhurtun

Pair Programming

31 Jan 2018

3 minute read

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?

Why we do it?

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!

“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)

How we pair?

A good pair should:

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)

References:

Books :


Return to Blogs.