Finding the biting point with pair programming

The inevitable imbalance in pair programming.

At some point throughout a developers career, no matter their experience, they will most likely find themselves in a situation where they are either the Junior or the Senior of the two in a pair programming session. In this context, being the Junior does not only mean being a less experienced developer, but it could also mean somebody that has not been introduced to the current project yet, or someone who is inexperienced with the language.

When you find yourself in this situation, you might notice that the junior developer of the two struggles getting to grips with the code, and the senior might feel as if they are carrying the weight of the pairing session on their back. This can certainly end up frustrating for both. As a result, the senior developer will jump in the driving seat behind the keyboard and lead the way, not much is exchanged between the two and the junior developer will simply watch until whatever task is completed, maybe trying to ask a question or provide some help here or there.

So what happens when they switch roles? All of a sudden the junior of the two is put behind the keyboard and struggles to move forward. The senior will become frustrated and impatient, and both members of the team will feel uncomfortable working together, possibly creating tension within the entire working environment. This problem will stagnate and not go away because neither parties feel there is nothing they can do and in order to get the work done now, the senior developer must continue to carry the weight of the work on the back while the junior developer watches.

Even worse, what will happen when the junior developer will have to separate and work by themselves? This is both a cause and symptom of the junior developer sitting in the passenger seat too long. He was never able to drive for himself and as a result was never able to find the biting point of the software.

Finding the biting point?

When learning to drive a manual transmission car, the steps in order to move the car forward are as follows:

• Push the clutch down all the way with your left foot
• Put the car into first gear
• Slowly begin to put your right foot on the gas pedal
• Slowly lift your left foot off of the clutch until the car starts to accelerate

Finding the sweet spot where the clutch meets the gears was taught to me as 'Finding the biting point'. That biting point is a very specific feeling that you only experience once you have driven a car for yourself. You could watch someone work the pedals a thousand times but until you get behind them yourself you will never get used to their feedback or tension. To me, this intrinsic feeling also exists in software. I can remember times where I have been sitting in the back seat of a pairing session contributing sound and useful ideas and solutions. Once I was handed the keyboard I found myself stalling. This is because I was never able to find the biting point myself and gain my own understanding of the structure and feel of the code. This will most likely have to happen once, better sooner than later.

So what should I do?

As a Junior in the pair...

I know it's tough to admit ignorance, but everyone has to start somewhere. Ask questions often, if there's a task you think you can handle, ask for the keyboard, request that your partner guides you and is patient with you while you get to grips with the code. Study in your own time. If possible and if you haven't already, clone the repo on your machine and browse the code, branch off and try to add a new feature and see what will happen. Most importantly, be honest. There's nothing wrong with not knowing something, however the same can not be said about holding yourself back.

As a Senior in the pair...

Encourage your pair, at regular intervals pass them the keyboard and guide them. Answer their questions where possible. Most importantly, try to be patient. Remember that if you're teaching a less experienced developer, you're not only doing them a favour, but also strengthening your entire team.

It takes two to tango.

If you are trying to teach someone who is clearly showing they are not interested in learning, know that you've tried you're best and don't exert further effort until they are willing. Alternatively, if you're eager to grab the keyboard from someone who is being particularly stubborn, it's probably best to not stir further and just wait for a better opportunity. However this isn't an opportunity to completely switch off, continue contributing where possible.

Good results will require effort and good will from both sides. Providing that that can be managed, there's no reason for you not to be strengthening your team during every pairing session.