You’re staring at your code and thinking, “There’s nothing wrong here.”
But there is: the app isn’t working.
And you know the bug is staring you straight in the face. You finally turn to your colleague and begin explaining the problem, and suddenly, mid-phrase, it comes to you – the problem and the solution.
It seems all you really had to do was…start talking??
If you’ve ever had this experience with software development (I have, many times), you know that talking out loud is important when solving problems. Either talking aloud with fellow programmers or if working alone remotely, talking to a rubber duck (coined the rubber duck debugging method). Staring at code is also important, but not for too long.
So, get yourself a rubber duck, your colleagues say – seriously. Or better yet, get online and start pair programming together.
In a thorough treatment of Pair Programming, authors Birgitta Böckeler and Nina Siessegger describe how:
Pair programming forces us to discuss approaches and solutions, instead of only thinking them through in our own head. Saying and explaining things out loud pushes us to reflect if we really have the right understanding, or if we really have a good solution.
They quote Jean Bartik, one of the original programmers for the ENIAC computer in the 1950s, who said:
Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each other’s errors, and use the best ideas.
So we knew it then and we know it now: pairing two or more software developers together to solve a single problem, in front of a single screen, creates great software.
While not necessarily extreme programming or agile software development, pair programming can be used to allow team members to build and architect software and learn to trust each other.
Pair programming involves two programmers sharing a single computer and keyboard. This can be done online with screen sharing or tools built for pair programmers (see below).
The classic metaphor in pair programming is the driver and navigator. The driver is at the wheel, the navigator looks at the map; the driver types and the navigator describes the problem and solution.
They both work equally hard. For example:
As the driver is writing code and thinking, the navigator talks, analyses, tests – all the while looking over the driver’s shoulder.
The driver’s role is to structure the code, decide on the variable names, and write the loops, functions, and conditions that implement whatever the navigator is saying.
The navigator’s role is to shape the big-picture solution, frame the results, sets the constraints, does some code reviews.
The driver writes clean code. The navigator simplifies the problem.
Both driver and navigator design the architecture and decide on the database, technology, and the overall look and feel of the application.
Both driver and navigator are responsible for the final result, meeting the requirements of the original specs.
Driver and navigator celebrate together when they reach their destination.
Conflictual moments go to the heart of why we pair up. For example:
What is the difference between describing a “solution” and coding an “algorithm”? For example, the navigator says to put a red circle in the middle of a screen, at real-time speed. To do this, the navigator says to code an asynchronous program. The driver disagrees, there’s no need for risky and complex asynchronous algorithms. There’s a better solution. So, who wins?
What happens when the navigator doesn’t like the code?
What happens when the driver doesn’t like the navigator’s ideas or analysis?
There are always two options to solve these conflicts: either the pair stays in their roles (and trust each other) or they break out of their roles and humbly discuss the options.
That’s the whole point: pair programming is about communication and teamwork, where two experts patiently teach each other to be better at what they do.
That’s also why it’s good to switch roles, to have the navigator take the wheel and follow the guidance of the driver-now-turned-navigator.
There are often two pairing scenarios in pair programming:
Often, the latter scenario can make better use of a mentor-mentee situation, where the navigator not only establishes the big picture, but also might take over the typing to model for, teach, and share knowledge with the less experienced developer.
We all can always become better drivers, yet this senior-with-junior pairing enables a clearer mentor-mentee situation.
When two seniors are paired together, the responsibilities of each role may need to be further discussed and defined as they set out on their voyage.
We’ve discovered that pair programming works. On many levels: software engineering and softer aspects like teamwork and building up individual values.
In all scenarios, there are values at play: trust, candor, care, grit, and humbleness. Essentially, open communication reigns.
Learn to give feedback
Learn to receive feedback
Ask questions when blocked
Don’t be afraid of being wrong
Believe in your partner
Recognize and accept that others solve problems differently
Challenge each other
Motivate each other
Before finishing, it’s worth mentioning that all of this can be done remotely. Video conferencing with Zoom, Teams, Skype, and other such remote tools support screen sharing and even remote desktop control functionalities.
However, for more robust pairing features, you’ll want to use one of the tools that were built for remote pair programming like those listed below.
Here are some remote pair programming tool recommendations to assist you in your journey: