Pair Programming - what makes it hard?

Recently, after quite a long while, I had a Pair Programming Session again. I think it's been a good year since I last wrote JS. Let me share some valuable lessons I learned.

What we did

I found a nice little visualization tool on the Web, 100% JavaScript that we wanted to do something with. So, we forked the OpenSource Repo and got going.
The code was ... like ... nested functions within functions, if-else mountains, and our first thought was "Omg, we gotta refactor everything". Well, we just wanted to add some User Interface and customize a few things. It was a constant trial+error, and because the Repo came without a single Unit Test, we broke the app countless times. Well, we accomplished our goal and the app now does what we wanted.

Our approach

We had a vision and some ideas and just "nerded it". No upfront planning, no upfront design - we simply decided to pair up and do something spiffy. I started navigating, trying to get my ideas across of "how to do it". I don't consider myself much of a developer, so Navigator was totally fine.

Setting out

The first couple minutes were fine. "Let's do this ... ok, the code where we need to work is here. Now, all we got to do is add a function ... and a function call ..." I started to get tense. For a Clean Code fanatic, the code looked like a nightmare. About 700 LoC in the outer function, duplicate code, overridden variables - it could make you nauseous. 

Having created that kind of code before (cough), I didn't find it all too difficult to locate exactly where we had to work and which portions of existing code helped. For my driver, who was more used to Clean Code and had no JS experience, it was an entirely different story. He got lost in that code: Structure, syntax, purpose ... all a mystery. It was even more mysterious that it somehow worked.

What happened next

I started telling him specifically which line of code to go to. That helped. A bit. Next, I started telling him which variables to use. And which code to write. He became my secretary while I was dictating the code.

Soon, I grabbed the keyboard right across his lap, had my arms crossed with his - and started typing. That was a clear violation of my Navigator role.
I had lost my temper.

What I did about it

I realized I did the wrong thing. I withdrew. We quickly discussed what we wanted to do, then I turned to my own computer, minding my own business. We always came together when he made some progress. At least like that, he was free to work out his own solution, do his own experiments and gather his own learnings.

Within the same day, he could work the code completely free of my interference.

What I learned

Pair Programming isn't always the best approach to learn - especially when you're short on temper and lack the rules to keep you at bay. 

Rules that might have helped:

• Define clearly what a Navigator is allowed to do and what not
• Define clearly what the Driver does
• Hold each other accountable to staying in role
• Define driver-switch intervals. Don't let the Navigator get all jittery over a prolonged time

Meta-Learning: I have tremendous respect for navigators working with learning developers on messy legacy code. I didn't even last half an hour before I lost my patience.

I now consider Navigator a significantly more difficult role than Driver. Kudos to all who navigate well.