Why you should give Pair Programming a chance
As we’re trying to adapt to extreme programming paradigms at our workplace , pair programming was the first thing that I came across , and hated it.
Now what we don’t like to do tends to be shaped by our experience or what is similar to us and I realized I was working alone all this time , either facing a client alone , or even in a team the responsibilities were very properly divided, so I wasn’t facing any interventions, and hence what bothered me the most about working in pairs was the sharing of control.
Unfortunately, Working alone is the way most of us are taught our trade in our industry, and I saw a lot of people of similar experience as mine struggling whenever it came to pair programming.
Here’s what all bothered me, so if you can relate, keep reading,
- Being told not to copy the signature of a method or class , only to rename it later, because there is an opinion that it helps you memorize the syntax.
- The stupid dictation where someone asks you to define a class and spells it out for you .. “See-el-ae-ess-ess”
- The zoning out of my pair to an extent that they forget what we were about to do
- The clinginess of it, like there is one person who is going to stick around you for the rest of the day , like alright I’m an introvert and that’s too much human interaction for me.
- The fear of judgement , like it’s so much easier to go in the wrong direction and then correct yourself quickly when you’re working alone.
- The satisfaction that is missing at the end of the day because I didn’t do it all myself.
- Lesser sense of accomplishment
A little bit of research and talking to Experienced Coaches including Ammar Rizvi and Dragan Stepanovic, about it helped me , and here I am sharing my learning.
How pair programming works:
- There is a driver and a navigator , the driver writes code , and the navigator reviews each line while it is typed.
- The two programmers switch roles after a pre-debated time.
- The navigators has to consider the strategic direction of work , and has to be the guide on better approaches while working , so the responsibility of writing code and how it should be written is in the hands of the driver and the navigator has to look into the tactical aspects of completing the task, and be the safety net and guide.
What all you should consider while pairing
- Kindness, consideration and respect are the ground rules for setting up a good teamwork , and pairing is all about teamwork.
- People in general don’t like dictation so while being a navigator , work on your tone, and when disagreeing , talk in terms of benefit
- Communicate whenever you feel uneasy, voice out your concerns.
- Say the line number and file name when you’re communicating your thoughts
- Always bestow compliments
What pair programming solves for
- Eliminates the reviewers time and energy consumed in the PR review , because every word you write is already being reviewed by your pair
- No one has to wait around to get their PRs approved and we can ship fast
- The pressure of handling something new and difficult is shared so there is psychological safety
- In case of delays in the release , the pressure of answering questions is also shared , psychological safety again
- You get to make mistakes in front of a person, so it helps you eliminate that fear you developed growing up
- Helps you build better relationships with your team members , because you’re spending more time with them
- Lesser chance of a feature getting delayed because there is two intelligent brains rather than one
- Good learning opportunity for both people, because you get to experience contradicting belief systems and approaches
Why is it difficult to adapt ?
The difficulty lies with respect to prior experience and the habits and personality we build growing up.
You would notice fresh grads and younger engineers feeling very nicely about pair programming because they are getting appropriate help with it, and it’s easier to build habits when you’re just starting out. Whereas engineers with prior experience of only working alone and individually find it very tough to work in pairs because it’s tough to change a habit of years.
- Keep trying , Just keep swimming
About personality, some people are extreme introverts and they authentically don’t like a lot of human interaction (used to be the case with me , and sometimes still is).
- Take breaks , communicate about any and all uneasiness
Some people feel frustrated with very strong opinions and heated arguments, and environments that are perhaps lacking respect for other people.
- Learn, and keep trying to create a healthy learning space for other people as well. Be respectful.
Some people find it difficult to voice their opinions
- Having frequent retrospectives and short 1 on 1 meetings can help in this case.
There is a fair chance you might not feel comfortable with pair programming even after 3–4 times of working like that
- Find someone nice to pair with , pair with your friend for that matter
Lastly , I think it’s important to take time to analyze and understand any concept before implementing it and also before rejecting it , but just in case nothing convinces you , you can let it go.
“Before dismissing an idea it is worthwhile really trying it and trying it in a proper way in order to be able to judge and have opinion about it”
