Why Pair Programming Is Fantastic
Tags: Beginners Guide, Pair Programming, Code, Programming, Agile

What is Pair Programming?

Simply put, pair programming is an agile technique where two programmers work on a problem at a single workstation.

Workstation requirements:

One computer Two keyboards Two mice One monitor or two mirrored monitors

Writing code is not everything, but understanding the problem is.

The art of problem-solving

As Richard Feynman’s technique points out, thinking out loud and explaining the problem or a solution to someone is the simplest way to tackle a problem. The simpler the explanation, the better the understanding.

Solving tiny problems at a time and, in turn, achieving smaller milestones, is crucial in problem-solving. Therefore, the problem is first broken down into tiny achievable tasks.

In general, the software engineering process encourages programmers to ask as many questions as possible regarding the problem. When, why, how, where, etc. Some things can be assumed — like that limits that need to be set, and ultimately the solution needs to be full-proof that passes most edge cases. The solution should assure easy understandability, extensibility, and long term maintainability. To write tests for success, failures, and important edge cases one should know what those cases are which can be found out by asking good questions.

The most common mistake programmers make is to jump into solutions. The creative process needs time and iterations. Try to avoid this mistake by taking enough time to understand the problem at hand so you don’t end up solving the wrong problem or rather in a wrong manner.

The pair programming technique involves two people working on a single block of code, one driving the process and providing a high-level bird’s eye view of the steps called the Navigator. With the counterpart typing out the code and taking take care of the semantics called the Driver.

Steps involved:

Once the problem is fully understood, the pairs will then break it down into much smaller independent tasks that can be achieved in a relatively small amount of time. The pairs should have a basic understanding of the standard practices and conventions that are adapted in the codebase, which has to be written down in a document. The list of the standard practices I follow is listed here. The pairs should agree upon when to break. If possible, set a timer before starting the task. The most popular technique, Pomodoro, is ideal to make sure pairs don’t get worn out due to prolonged intense work. If Test-Driven Development is a common practice at your workplace, the roles can use the Ping Pong Method to switch roles after every Pomodoro session.

Now, let’s understand the roles of the pair.

Roles of a navigator:

The navigator is responsible for the “tactical” mode of thinking. The navigator ideates, and share thoughts and opinions by asking good questions about the driver’s thought process and reasoning behind the code.

The navigator is an onlooker who can catch and point out any syntactical errors and typos immediately. The navigator also must keep each other on track. To ensure that one does not get lost in the rabbit hole as the driver is in the deeply focused mode to worry about the nitty-gritty. An extra set of eyes for a reality check is always helpful.

As a live reviewer, the navigator helps reduce the complexity and efforts required for peer review in the process. Any potential bugs can be caught sooner and the code can be modified immediately — improving the quality of the code as a result.

A navigator makes notes and is involved in high-level problem solving by speaking out loud and ideating about the algorithm involved.

Roles of a driver:

The role of the driver sounds simple, but coding is not just merely typing something on the keyboard. Writing code requires a deep, undivided, focused mode of thinking. Not to mention this job is quite demanding and requires intense mind power to solve complex problems in the form of code. Therefore, the process involves multiple steps, but the driver’s job is to stay focused on the tiny task at hand.

The driver just needs to first think out loud about what their thought process is in achieving this task. Once agreed upon the solution the last step will be writing out the code. When encountered with obstacles or glitches the two parties decide upon how to go forward.

Sometimes when you’re hit with an impasse, it’s better to take a break, meditate, go for a run, take a nap, or play a game before revisiting the problem.

I want to leave you by saying:

When it comes to programming, a pair is greater than two.