Pair programming

Pair programming

What is pair programming?

Pair programming is an agile practice and in its essence, it's about solving problems together

This means that two programmers work at one workstation and work on the same screen, mouse and keyboard (or remote with screenshare).

Why Pair programming? I can get more done on my own...

Web development is a team effort. A modern web development team can have up to 10 developers working on the same application. This means that communication and the ability to work professionally together is more important than ever.

So why should we work in teams rather than alone? Don’t we get much more done when working alone?

Well, this can be true in certain cases but the benefits of working in a pair far outweighs the benefits of working alone, especially as a junior developer.

Some benefits of working in pairs

• Your code is getting reviewed as you code by your team member

• Fewer typos resulting in fewer bugs and faster coding

• Great for junior developers to quickly understand the code.

• Pairs can discuss more solutions in a shorter amount of time.

• Enhanced ability to explain the solutions and notice errors in logic.

• Diverse coding skills result in smarter code.

Needless to say, Pair Programming is our primary learning technique here at Craft Academy.

So how is it done?

As with anything you need to have a plan and some rules before starting out with pair-programming.

First, you need to divide the roles: we will need a driver and a navigator.

The driver will type on the keyboard and explain what he is doing just like a narrator explains what’s happening in a nature show.

The navigator will closely follow what the driver is doing, taking notice of typos, give suggestions, taking notes, making sure that the driver is staying in scope and try to be one step ahead in the planning.

"

Two coders disguised as a navigator and a rally driver"

The driver and navigator plan the session together by answering following questions:

• What are we working on?

• What is the scope?

• When do we know that we have completed the task or feature?

• Do we have a user story to work from?

• How often should we switch roles?

You can either work for 25 minutes and then switch roles, or you can switch roles after making the tests go green

It all depends on how complicated the code is and how long it takes. But 25 minutes is a good rule of thumb.

Do’s and don’ts

Do take care of your personal hygiene, especially when working closely at the same workstation.

Do ask questions when you are unsure of what to do next or if you don’t understand.

Do use the proper language eg “we” and “us” instead of “me” and “I” to fortify the collaboration.

Do think about personal space.

Do commit and push your code regularly

Don’t snatch the keyboard from the driver

Don't stop communicating regardless if you're the driver or the navigator"

Don’t do anything else while navigating, like looking at your phone or going through your email

Don’t try to always be right, make sure to listen and try out suggestions.

Troubleshooting

Do you feel like pairing up is ineffective? Here are some indicators of non-performance.

Disengagement- when a member physically withdraws from the workstation or does something else like looking on phone or accesses email

Solution: Take a break or switch roles.

Watch the Master -when one member is more experienced than the other thus making the junior member take the observer role, which leads to disengagement.

Solution: Stop, review and explain the code and switch roles.

Silence- when one of the members is silent.

Solution: Take a break and have a talk.

Some final words

It takes two to make a pairing session work, and remember just like everything else this pair programming also requires practice.

There will be very few challenges in this boot camp where you are required to code alone, and this is because we strongly believe that two coders produce better code.