Pairing

Last weekend I participated in the Global Day of Code Retreat here in Austin. I was impressed at the diveristy of participants, the overall good nature of those there, and what I was able to learn even while pairing with relative beginners. When I got there, there were 3 women and 3 men in the room. By the end of the day there were about 6 women and 10 men. At least 6 of the participants grew up in foreign countries. It was, for a computer meetup on a Saturday, a fairly diverse crowd. I was impressed. ...

Pairing is hard, but to me, the hardest part about remote pairing is not technology or even logistics, it’s collaboration and problem solving together. To that end, there are multiple pairing styles that are worth looking at when you’re trying to pair with someone knew. Each style facilitates collaboration differently and knowing how they work helps. Driver / Navigator Fundamental Idea One partner “drives” at the keyboard, focusing on implementing. The other partner “navigates” verbally, focusing on big ideas, questions, typos, and conventions. ...

The other night, I got to pair with @piisalie to learn some Emacs and work through a little exercism.io. Paul is a relatively new developer, but he’s been studying under the tutelage of @jeg2 and getting ramped up very quickly as a result. It’s neat to see people who are able to absorb so much so quickly. Setup Google+ Hangouts TMUX + Emacs (Ahhhhhhhhhhh!!) Paul was pretty familiar with Emacs and did a good job showing me around. We worked on a small exercise and I tried to do as much of the editing as possible as he guided me when I said “how do I move up and down again?” ...

I gave a quick lightning talk on how to have a good #pairiwthme session at LSRC this year. I still had a question on how to get started in pairing afterward. I came up with a basic set of steps, which can be combined as needed. Get a pairing session scheduled and established. Share a screen. Type together. Sometimes this takes longer… sometimes it’s just a few minutes. Work on the simplest possible setup you’re comfortable with. Usually this is Google+ and ScreenHero, but YMMV. Work toward an optimal setup you’re comfortable with that maximizes responsiveness and communication. Typically this is low bandwidth (i.e. Audio Only (Skype?) and terminal sharing (tmux)) You may be able to get all the way to step 3 in your first session, or you may take 3 separate sessions to get all the way there. Either way, you’ll get there, and then you’ll be comfortable enough to take someone else through it. ...

I finally got a chance to pair with @jnanney tonight. He had a project dealing with the OnStar API that needed OAuth Authentication, so we took a stab at implementing it. Setup Skype - TIL Skype 6.x turns off your video if you connect to a Skype 2.0 client–but the audio still works! TMUX+VIM on a slice (not local) Experience We started by making some large, rough ideas about what we wanted to accomplish and then began looking up some things on OAuth2 to help us accomplish them. Pretty quickly we stopped driving everything via tests and started exploring via IRB. ...

Last week I had the opportunity to pair again with @willpragnell. He had just moved and didn’t have internet access, so I suggested that we try a “mute” pairing session from a coffee shop, where all our communication happened through VIM. He was game, so we started off with a quick chat session on Google+ to get set up, and then switched to a VIM+TMUX setup for the rest of the time. ...

12 Lessons I learned from Unit Tests/TDD is a great article for practically adding TDD to your teams rhythm. I can’t stress enough how much point 8 makes a difference: Pair programming helps the team to adopt TDD. When we are trying TDD for the first time or when our deadline is tight, we will have the will to forget the tests and write only production code. Pair programming will prevent the team to cut corners and will keep it writing tests. ...

Today I got to pair with Peter Vanderabeele, who is a programmer from Belgium with a highly methodical bent. He has clearly had a lot of experience and it was neat to get to work on his project since it isn’t every day you get to work on a high performance fact storage system. Peter is creating a data store meant to store semantic facts that have relationships to each other. It’s a very different project with a goal, he stated, to have data in this format and extractable for the next 50 years. To try to view code with that lens is very different from how most other Rubyists think. We tend to see our code dying in the next 5 years… max. So we make decisions with that timeline in mind. Thinking of a timeline longer than my own life has very different implications. ...

Last night’s pair session was with @stuartrexking - a very experienced developer and technologist currently working at a really neat company called Antipodean Labs. It seems like he’s got a great handle on solving problems and staying maintainable. We started off by trying to decide what to do. I’m increasingly convinced this is the possibly the hardest part of remote pairing with people who aren’t part of your company. You don’t have a predefined complex project you both find interest in, so the most likely shared interests are either meta problems or highly common ones. Highly common ones are very visible and difficult to find low hanging fruit for. The meta problems are good to solve, but somehow feel like they are less valuable than the “real” problems. Maybe this is just a feeling I have. ...

I had a great #pairwithme session with @_zph. Always a pleasure to talk to him and solve a problem together. Setup TMUX + VIM on a slice github-auth gem Experience We wanted to add the feature to gh-auth so you could pass a –path or –user argument to it. Because we’re good developers, we started off by coding the acceptance test. We discussed the merits of how to write good tests and whether to follow convetions within a gem authored by someone else or do things ’the right way’ – according to whatever coding religion you follow. Eventually we decided on sticking to the conventions of the gem while trying to improve–but not radically change–the tests/testing that we touched. From there, we dove down into the implementation and unit tests and drove through until we had the –path argument working. Along the way we did a little refactoring to use the OptionParser instead of requiring a specific ordering of options. ...