The setup

I have been doing pair programming in one form of another for nearly 10 years. I have mentioned before that is a superior experience/approach for work within a team. But, not long ago I realized that my preferred approach to it is one that is not often mentioned (or at all). And I believe is an approach that improves the results of the technique.

The learning of it

There are multiple places where you can learn about Pair Programming, like the fantastic Agile Technical Practices Distilled (by my ex-colleagues Santos, Consolaro and Di Gioia), or this very informative post that I have linked to before on Martin Fowler’s website by Böckeler and Siesseger. I thoroughly recommend to read, understand and start practicing pair programming based on their wisdom.

Of course nothing like practicing, and for that something like the London Code Dojo or the LSCC are good places where you can give it a try if it is not done at you work.

Code is design

I have mentioned a few times this idea (one of my main ideas). When you are coding, you are designing, on the big and on the small. You design for performance, or for maintanability, or for cleanliness, or security, or for something else. The primary thing that you do, then, is thinking.

Programming/coding is not akin to layering bricks. Is more of a mixture of building architecture, and home/office design. The code is a blueprint, is your architectural plans.

The mechanical side of it

I have been always a proponent of learning proper touch-typing techniques (using all fingers, not needing to look at the keyboard). But this is not because it will make you a better programmer. The use of a keyboard to write code is a temporal situation (however long it becomes) and not central to the activity of programming itself. But is important for the same reason that being able to punch cards was important before. The quicker you go, and the less mistakes you make, the more you can concentrate into the actual proper activity. Typing is not what you have to do, but is something that slows you down. The same applies to knowing your editor (be that Emacs, VsCode, IntelliJ or Vim) or any other tooling (cargo, leiningen, …). Same reason why slow computers and VMs are detrimental for the activity.

Maybe one day, following what some trailblazers have done out of necessity (check this presentation by Travis Rudd), we will be using mostly voice for our code. Or maybe the work being done at the moment for limb prosthetics means that we will be able to plug in nervous system directly into computers as an input method.

Pair programming main activity

Pair programming is about improving design, avoid going down bad paths, increasing the quality of the code. Two heads think better than one. And the use of the keyboard is circumstantial to the activity.

The standard driver/navigagor approach is a good approach to learn pair programming, and helps in developing the stamina needed (pomodoros is another great tool for it). The problem that you have with the driver/navigator is that on the strict approach, the driver doesn’t really participate in the discussion for solving the issue. Which means that even you have two brains, only one is working at a time.

But it should always be two people talking with each other, discussing what needs to be done, disregarding who has the keyboard. Pair programming is an activity about two people communicating constantly to design a good solution to the issue at hand.