Pair programming
For those who didn’t know I have been a software engineer for over 6 years now. My first jobs out of uni was in a (initially) small company that subscribed to many of the agile and lean practices. This is where I experienced working side by side with people of different skills, experience levels and roles, and where my love for teamwork and pair programming grew.
This post will be a bit different from the rest because I will present a little info on Pair Programming and why I think any team should try it.
Two heads are better than one
We all know the saying “Two heads are better than one“, this definitely applies to pair programming and why it can be so helpful for the healthy functioning of a team and the quality of work.
Pair programming is a software development technique where two individuals work together on the same piece of code.
There are two roles involved in this technique:
The driver - they are in charge of the keyboard, typing what the navigator communicates
The navigator - they are providing the direction of the code
To keep things balanced the two switch roles regularly, in this way the perspectives change and the design is more balanced. To do this effectively the two individuals have to be in constant communication, both participating in outlining the code.
Tips and tricks
Plan beforehand - make sure you both understand the acceptance criteria and talk through the direction of the approach, breaking down the problem
Test driven development - try writing the test first and exchange roles to write the code that causes the test to pass
Get a list of tasks and tick them as you go - make notes of the things that need to be achieved and new ideas as they come up and try to keep to one task area at a time
Ask questions such as: “How do you …?“, “What should we …?“, “Why do you think …?“, “What about ...?“
Speak-up when typing - it’s great to continuously say out loud what you are typing, this will keep the focus on the screen and highlight any misunderstandings
Don’t be afraid to bring the discussion back on the task at hand
Leave your phone behind
This sounds easy in theory but can take many wrong turns before reaching the right speed and direction especially with people new to it.
Potential bumps in the road
The adjustment period - Sitting at the same desk or in a 1-2-1 conversation with someone you aren’t used to can be fairly daunting and uncomfortable. It takes some time to adapt to each other’s way of thinking through problems and prioritising. It is also even more clumsy when the styles of communication are different (extrovert vs introvert, detail orientated vs big picture). Remember, you both bring new ways of looking at things and it helps sharpen your knowledge, and your negotiation skills, resulting in an overall better plan and code base.
Takes longer and uses more resources - This is one of the reasons the business might not be willing to accept pair programming as a practice. Two people working on the same task might seem counter-productive but in the long run this improves code quality and produces 15% less defects that otherwise would have required more development time and created a more unstable product.
Navigator loses interest - this is very common when the driver takes control and doesn’t communicate their ideas. One solution could be implementing a strong style pairing in which the navigator makes all the decisions and the driver has to switch places if they want to control the direction.
Exhaustion - It is important to understand both individuals’ needs and take regular breaks or pair program only for a specific set of time or tasks.
Not every project is suited - Some tasks are simple and repetitive, these don’t require a second pair of eyes and that is ok. It could be a good idea to discuss in planning sessions which of the tasks that are appropriate for pairing and would benefit from knowledge sharing and pair support.
In time the benefits outgrow and overcome the bumps in the road.
Benefits of pair programming
Knowledge sharing - whether one of the developers is more experienced or not, pair programming helps better understand the task at hand and how everything is connected within the software. This means both people will have more knowledge to take future design decisions and find the work easier. This is also a great way to introduce more junior roles to parts of the code base as it’s a more direct way to learn practices and software architecture than using tutorials or books.
2 modes of thinking – when two people are thinking about a problem they both come with different ways to look at it. Sometimes even saying something in a different way can uncover a solution or a new path.
Code review on the go - the result of pair programming is clearer and more maintainable code, which gives confidence in the work created and doesn’t require thorough review.
Focus – pair programming keeps the people involved focused on the task at hand, having another person there can keep you accountable which increases productivity.
Collective code ownership - helps with removing blame culture and defensiveness when refactoring is required and creates a sense of common work and shared responsibility.
Breaking down silos - silos are unhelpful in a software team, having one developer that is the only one with the specialised knowledge to answer questions and make decisions is a clear path to disaster. Sharing the information balances the knowledge of the entire team. In time when tasks are on the board anyone can pick one up and understand it.
Better code quality - this comes back to the fact that two minds are working on this, they bring separate experiences that enrich the quality of the code. They can separately notice things that the other might not on their own.
Team flow and communication - this is probably one of the most hidden benefits of pair programming but also one of my favourites because so many times the discomfort I felt in working with someone I didn’t quite know was transformed into true respect for the uniqueness of the other, and even affection for their sometimes unusual ways of doing things.