Pair programming is a tool of agile programming methodology, one we leverage on a regular basis as Kuika development team. Pairing has become a very productive technique for us. We adopted it in our software development methodology – you can read more on our software development strategy on another blog post. In this post, I, as a junior software engineer, am going to share my experiences with pair programming. To do this, I will go into details of how we adopt pair programming, our observations about its benefits and possible drawbacks, and how we use it in practice for maximum benefit.
1. How We Decide When To Use Pair Programming
We resort to pair programming a lot. To put it in numbers, we program in pairs more than 50% of the work in a sprint.
We ask two questions to decide whether a work item will be done by pair programming or by a single programmer:
2. How We Benefit
We use pair programming as a tool that increases our team performance. We systematically incorporated it into our software development methodology.
2.1. We Share and Multiply Knowledge
If we would rather do pair programming for a particular job but there are no two programmers simultaneously available, we assign the job to a single programmer. Next time when we come across a task under the same topic, we do pair programming. The person who had warmed up on that subject does pair programming with someone else. This way, we leverage pair programming as a tool to share knowledge among team members.
2.2. We Save Time
As mentioned in a previous post, we use pair programming to reduce the time needed to complete a job. Two people together make decisions a lot faster, identify code reuse opportunities better, better use design patterns, and makes distractions less likely. For example, we manage to complete a work item in less than one day , although it would normally take 2 person days for one programmer. This proposition holds even for senior-junior pairings.
As Kuika, we are dedicated to be always agile. We aim to develop and release deployable units within short time frames. Therefore time constraints influence our answers to the questions on how to prioritize tasks for pair programming, particularly when a work item is a prerequisite for another work item. In this case, completing the prerequisite task on time is doubly important. We benefit from pair programming as a life saver with which we reduce the time allocated to the job considerably.
Shortly, if used consciously, pair programming can be a very useful tool when it comes to time management.
2.3. We Focus More
I believe pair programming certainly provides self-discipline to both parties. One can be easily distracted after a certain amount of time when working solo. But when in a pair people feel different. Pair programming is an interaction process. It motivates people to respond and contribute. Peers dedicate themselves to the job. As a result, you are rewarded with a neat, reliable, and a consistent outcome .
Pair programming enables peers to think out loud, negotiate, and brainstorm. Very imaginative ideas can come up as a result.
Pair programming keeps people from being distracted for several hours, especially if you get distracted easily looking at information online. On the other hand, how pairing affects focus-level depends on the programmer’s characteristics. Some programmers may find it distracting, and prefer going solo except for the most complicated tasks.
Expertise of peers, characteristics and complexity of work, objectives regarding work item (being effective or efficient or both) affect a pair programming experience a lot. I will skip exploring those and their combinations, for it shall require another blog post itself.
2.4. We Invest in Testing and Code Review
When we are in pairs, both parties are more self-conscious, so criticism level increases. As a result, number of use case scenarios considered becomes larger when pairing.
A pair can multitask. When we are pairing, the “driver” focuses on implementation, while the “navigator” takes a chance to think outside the box. This gives the pair a room for maneuver to examine accountability of the code.
Pair programming lessens burden of testing and code review sessions.
3. How a Newbie Benefits
As a junior software developer, I am going through an orientation to numerous aspects of being a developer. I am in a phase in which I learn how to code as a team member. I am adopting the idea and objective behind the product. I am learning to collaborate. I am adapting to all these simultaneously.
Pair programming has been beneficial for me, maybe I am the one who takes advantage of it the most. Pairing with a more experienced programmer – in this case, every other programmer at Kuika – increases my pace of learning the product and the devtools dramatically. Pair programming has enabled the experienced programmers share their knowledge with me by actually illustrating it. This makes it much more easy to access resources and do a lot of practice in such a short time.
How is it like to pair with a newbie – with a mind like tabula rasa! – to a more experienced programmer? Well, I can only guess, but I think they have savings too! First of all, they save time to tutor me. Of course they give incredible effort to teach and guide, but thanks to pair programming they can do it during doing their daily work.
We exchange roles in a pair frequently to preserve dynamism.
When I am the “driver”, and my peer is the “navigator”, s/he comments on my choices of implementation. This is a priceless opportunity for a newbie to understand whys and hows. Moreover, I am being challenged to think fast and code.
When I am the “navigator”, I sit at an angle where I can see the code from outside. Given that as a newbie I am at the risk of getting lost in a relatively complex job, this is a chance for me to comprehend the logic behind implementation. The “driver” is concentrated on implementing, while I think outside the scenario from a wider perspective.
Evaluation and Conclusion
Programming in pairs may bring its own costs. If you apply pair programming excessively, you might be out of practice in terms of studying solo. This may cause lack of self confidence. Therefore it is important to be able to balance the two.
Peers have to put an effort to develop harmony. They need to get to know one another’s style and attitude. But it is worth it. They exchange experience and ideas in a very organic way. They cover each other’s weaknesses, while they combine their strengths. In long term, everyone evolves to be a better team player. The gains are invaluable for the team.
These are, as a junior to the field, my observations about pair programming. I believe pair programming is a powerful tool for a team, and a grace for a newbie.