Lately, our Designveloper team started implementing a new working method — Pair Programming, where is two programmers sitting side by side at one computer, sharing just a single workspace.
We were very nervous at the first time. You know, we, programmers got used to using our own swords and fighting solo when getting into the war. Then, suddenly you have to share your weapons with another guy, how confusing it could be?
Surprisingly, we have to admit that much like a cup of coffee a day, pairing tastes awful at first, but we end up liking it after just a few weeks imbibing of it repeatedly.
So in today’s post, I’m going to share with you some reasons why we fell in love with pair programming and why it’s a good idea for every ninja coder to give it a try.
WHAT EXACTLY IS PAIR PROGRAMMING?
In a nutshell, pair programming is when two programmers are coding together.
To make it easier to understand, let’s imagine when you and your friend are in the car. You’re driving and your friend is responsible for looking at the map and show the direction. The same can be said of pairing. In pair programming, while one developer is writing code and implementing solution, the other beside will keep an eye on the big picture and navigate.
How we actually pair at Designveloper
At Designveloper, we do pair programming slightly different.
Typically, in pair programming, it is recommended to use only one machine for both developers but we use two machines. The reason is that each developer has his/her own preferences, for example: text editor, IDE, font, color, screen resolution, place where his/her code resides, etc. Letting each developer works on his/her own machine would make the developer feel more comfortable. The other developer can also learn more from these preferences and he/she can pick what he/she wants.
However, the common mistake when 2 developers working on 2 machines is that the navigator tends to use his/her own machine while the other is coding. To avoid this problem, we explicitly require the navigator to close his/her own laptop.
2 laptops works best with a big monitor. It is recommended to have at least 23” monitor with 2 HDMI ports. Skype or Hangout screen sharing work best in case of working remotely. If 2 developers sitting next to each other but do not have an extra monitor, using built-in screen sharing feature of mac to keep 2 machines displaying the same is recommended.
Following is the instruction to setup screen sharing on Mac:
Throughout the process, programmers will switch role frequently, constantly talk to each other, especially do research together to keep both engaged.
We also have pair programming diary. At the end of everyday, the lessons learnt will be documented. In the end of a working week, all the lessons could be used for sharing via a blog post for example.
How we measure pair programming
It would never be easy to measure the value. That’s why we use Hubstaff to track all the work and get invaluable insights about the real result programmers produce.
TYPE OF PAIR PROGRAMMING
The following are 3 typical pair combinations:
Expert — expert
Since both members of the team are experienced, they can produce the best quality for sure. The thing is there’s always something more to learn but experts used not to make questions. And as a result, they normally lose their creativity and less likely to introduce new solution.
Expert — novice
This will be a great opportunity for the novice learn more from the expert. When the novice raises questions, the expert have to think over and explain. This Questions & Answers process can lead to the best new solution.
Nonetheless, make sure the novice is active. If not, the novice may end up just watching and the expert will feel annoyed. This is the watch-the-master phenomenon.
Novice — novice
Obviously, two novices pairing can give better result than they working independently. But this combination is discouraged.
BENEFITS OF PAIR PROGRAMMING
We’re gaining huge benefits from pair programming:
Better product quality
As usual, after the code is written, we need to review it to improve the quality. The things is even though you try your best to focus on reading your code again and again, you still might not come up with some suggestions for a better quality.
But with pair programming, the review process will be done WHILE the code is being written. It sure make the code nicer, reduce the risk of errors and failures.
Moreover, two heads are always better than one. A solo developers can’t think up more alternatives when proceeding than a pair could. And as the result, it leads to better design quality.
Better team knowledge
Let’s face the fact that humans fundamentally like being social. And pairing means more communication. It gives chances to make friends with the ones we normally don’t hang out with. In consequences, it builds trust inside the team and makes employees comfortable. Happy employees help us to build a productive and effective team for sure.
Everyone makes mistakes. Sometimes, to solve the problem you just need a simple solution but somehow you can’t realize it by yourself. In pair programming process, we will constantly and easily learn from our partners.
When an expert and a novice are paired, we can save ourselves a lot of headache and time in training newbies. Pair programming could be a good way to strengthen each other skills faster.
Saving time, getting more money
If you think that having two programmers work on a task will double the hour it takes to do that task, you’re wrong! I did think the same at the beginning.
A study run by Laurie Williams from the University of Utah shows that pairs just spend about 15% more time on programs than individuals (Figure 1). However, the resulting code has about 15% fewer defects (Figure 2). Let’s take a look at two charts below:
Figure 1: Programmer Time
Figure 2: Code Defects
Having a second set of eyes can help us debug faster. Time saving is obviously equal to more money!