I was recently able to work on a project with a fellow apprentice. It was an amazing opportunity and I had a blast working on it. But it was also two weeks and change of non-stop pairing. I've paired before. I've even paired that long before, but not with one individual. And it had been a year or so since I had to put my pairing skills, learned through the late and great Dev Bootcamp (DBC) to use. It was a learning experience for sure.
Communication Is Key
While I got to pair with a super great person, spending that much time problem solving with any one individual is going to be a challenge no matter what. I wasn't as diligent as I had been while at DBC to check-in frequently, but we made sure to check with each other every day. Earlier on, we ran into a speed-bump, but were able to talk through why we were both having a hard time and the project was smooth sailing from that point on. Not because things got easier, but because we made sure to continue to communicate and do our best to implement the feedback we received from each other.
Learning and Teaching
No one is ever going to be on the very same page as you when you're pairing. There's no guarantee that you're even going to be in the same book. While my pair and I were in relatively the same spot in our careers, we had different strengths and weaknesses, and brought different knowledge to the table. We both learned a great deal from each other and still managed to deliver way more on that project than we could have if either of us had been working individually.
Calm Down and Slow Down
There's a joke somewhere about me being a force of nature, but the reality is that my coding philosophy is that there's no better way to research than to try. The docs, Stack Overflow, blog posts, and even mentors, they can all be very helpful in answering questions, but at the end of the day, the best way to find out if the code can do something is to try that something and see what happens. Of course, sometimes it's easier to Google "array length in ruby" to figure out what a method is called instead of going through every iteration until irb or your tests stop yelling at you. This attitude of try first often makes my style look haphazard and reckless. It's not quite as reckless as it seems, since if I implement something and it "just works" I try my best not to just charge forward. I do my more traditional research after I experiment. A method I developed in the past after pairing with much more research-oriented and analytical people, and I think I've become a better developer for it.
This is a great workflow for me because I can accomplish a lot, and I have the benefit of more targeted searches. Plus as I get more familiar with the language/framework/library, I don't have to do as much research because my knowledge is usually at the point where I feel comfortable enough with the mechanics to not have to verify my understanding. And that's where this starts to fall down in pairing. First of all, a lot of people are put off by my fast paced and fearless "let's see what happens" attitude. So I try to make my style clear to begin with. But it's not clear if I say I research at the end, and then leave it off because I personally am familiar. This is another point where slowing down and checking-in is important, or else it ends up being less "pairing" and more "soloing with a witness".