Pairing on Bridge

Code Retreat

Thu, 19 Dec 2013 00:00:00 +0000

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.

Different Pairing Styles

Sat, 16 Nov 2013 00:00:00 +0000

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.

Pairing Post Mortem - @piisalie - Emacs and Exercism.io

Fri, 09 Aug 2013 00:00:00 +0000

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?”

The #pairwithme Progression

Sat, 20 Jul 2013 00:00:00 +0000

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.

Pairing Post Mortem - @jnanney - OAuth

Thu, 18 Jul 2013 00:00:00 +0000

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.

Pairing Post Mortem - @willpragnell - Mute Pairing with VIM

Tue, 09 Jul 2013 00:00:00 +0000

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.

TDD And Pairing Will Save You

Tue, 09 Jul 2013 00:00:00 +0000

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.

Pairing Post Mortem - @peter_v - Improving a Semantic Store

Wed, 03 Jul 2013 00:00:00 +0000

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.

Pairing Post Mortem - @stuartrexking - Cane Extension

Mon, 24 Jun 2013 00:00:00 +0000

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.

Pairing Post Mortem - @_zph - Meta Pull Requests

Wed, 19 Jun 2013 00:00:00 +0000

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.

Pairing Post Mortem - @Shicholas - String Calculator

Tue, 18 Jun 2013 00:00:00 +0000

Last night I had a great pairing with @Shicholas working on the String Calculator kata.

Setup

We again used TMUX + VIM, even though Nick wasn’t very familiar with VIM. Based on his experience, I think this might be the best way to learn VIM since you have someone guiding you through. You won’t pick up on everything, but you’ll learn a handful of new things each time.

Exercise

We went through each of the different rules and ping ponged back and forth. It was a struggle to do the simplest possible thing every time, and really let the tests DRIVE your development. Your developer brain wants to generalize the solution to a problem, but the strength of TDD is keeping your actual solution as simple as possible. Developers are notorious for over complicating things and over desigining.

Pairing Post Mortem - @hinbody - Attacking Open Source is Hard

Fri, 14 Jun 2013 00:00:00 +0000

The easiest things to pair on are little tasks that you both understand and can be easily “completed” within a 1-2 hour pairing session. Unfortunately, Tic Tac Toe, Conway’s Game of Life and Bowling become stale quickly. It’s not that they don’t have valuable things to teach you, but you can’t pair with the same people over and over again just doing those problems. Eventually you need to dive into a real project.

Pairing Post Mortem - @willpragnell - Overseas TDD

Fri, 14 Jun 2013 00:00:00 +0000

I had my first pairing session with @willpragnell today. He’s a smart guy and my first European pair partner. It was a pleasure to talk to him about his iOS and Ruby experience and I picked up on a lot of little things from our pairing session together.

Setup

TMUX and VIM - (I got to use my newly revised pairing script to set up everything in seconds)
TicTacToe - RSpec

The Session

We set a couple of goals out for the beginning. We both wanted to learn more of RSpec’s new syntax and we wanted to really adhear to the TDD principle of doing the most simple thing next.

Watch and Learn

Fri, 07 Jun 2013 00:00:00 +0000

I’ve now been pairing with several people a week for the last few weeks. Even over that short period of time, I’ve seen a pattern emerge:

If you watch someone else (of any skill level) and pay attention, you will learn.

When I’m watching others, I tend to be thinking of what I’d do in their situation, but sometimes just observing very simple things a user does – a VIM action, a command line script, an obscure API call, a rare tool – these are the details that change you in the small over time. This same principle is why counselors tell you to actively listen to your spouse – hear what they’re saying instead of just thinking of what you’re about to say. Sometimes you pick up on things they might not be able to vocalize themselves. Sometimes you pick up on emotions you would be too busy to notice otherwise. Actively listening in any relationship involves shutting up and noticing the details–it just happens to be true when you’re pair programming as well.

Pairing Post Mortem - @mattr_ - Pending Specs and Assertions First

Thu, 06 Jun 2013 00:00:00 +0000

Today I paired with @mattr_ and got quite a bit of good input regarding how to attack a problem and write tests. Matt is a super smart guy who has really absorbed some of the fundamentals of TDD and it shows through his ability to break down a problem.

Setup

TMUX & VIM on my box
Conway’s Game of Life as an exercise

Process

When implementing the game of life, we started off looking at the problem on Wikipedia and found the 4 rules. I immediately started writing the first test when Matt noted that he liked to write all the specs he knows of as pending specs right at the beginning. Then he can really plow forward and know what’s next. He also noted that he likes to be able to write the assertion first, based on the test, and then build the test up from there. I felt the lightbulb go off when he pointed these two things out. When I’ve struggled to find the test or figure out how to test something, usually it’s because I can’t figure out how to get to the assertion, and that really comes down to not testing the right thing.

Pairing Post Mortem - The Mistake

Thu, 06 Jun 2013 00:00:00 +0000

{% blockquote Chris Knight and Lazlo Holyfeld http://www.imdb.com/title/tt0089886/trivia?item=qt0435761 Real Genius %} “How’d I do? I passed! But I failed! Yeah!” “Well, then I’m happy and sad for you.”

Last night I made a mistake. In an effort to continue pairing with people I really enjoyed pairing with, I scheduled 2 pairing sessions for the same evening. I left 30 minutes between them, I prepared as I should… but I was stressed and it made both sessions worse.

Quick Script for TMUX pair sessions

Thu, 06 Jun 2013 00:00:00 +0000

Update 2013-06-14: Improved the script, removing the github-auth dependency, some of the OS X dependencies, and added firewall punch-through (user specific) and ssh-command with external IP auto-copy to clipboard

I wanted a quick and easy way to set up a new TMUX session with a brand new pair, so I came up with this:

#!/bin/sh
gh-auth add $1
sudo cp ~/.ssh/authorized_keys /Users/pair/.ssh/authorized_keys
sudo chown pair:staff /Users/pair/.ssh/authorized_keys
gh-auth remove $1
tmux -S /tmp/pairing new -ds pairing && chgrp staff /tmp/pairing && tmux -S /tmp/pairing attach -t pairing
sudo rm -f /Users/pair/.ssh/authorized_keys

That will download ssh keys, create a tmux session, and attach to it. When you’re done it will cleanup so the other person has no access to your box.

Pairing Post Mortem - @_zph - VIM and a Gem

Wed, 05 Jun 2013 00:00:00 +0000

Last night I had a great #pairwithme session with @_zph. He’s been doing Ruby on nights and weekends for the last few years and he’s been using VIM much longer than I have. I learned a lot of little tricks about VIM that I just hadn’t quite worked out before. We also refactored some of his Buff Gem.

Setup:

Zander had a VPS already provisioned with my ssh keys installed. Super Easy setup.
TMUX + VIM for our editors
RSpec for testing the Gem

We started off trying to think of what to pair on within Zander’s gem. He was concerned about the tests, so we actually spent a fair amount of time just looking at the WebMocked tests and discussing the pros and cons. Eventually we decided that WebMock might be a good way to start off your TDD of an API wrapper since you have complete control of the response, but VCR gives you the best long term support since you can both get fast tests and confirm that you’re still working with the API correctly and that you didn’t just magically stub out the wrong thing–just delete your cassette and you’ve got “free” real API tests, followed by nice fast tests.

Pairing Post Mortem - @Shicholas - Real World Lessons and Bowling

Tue, 04 Jun 2013 00:00:00 +0000

Last night I had my first pairing session with @shicholas. Nick recently graduated from law school and is looking to pass the bar, but somehow programming calls to him. It’s a good thing too, since he’s clearly gifted and a fast learner.

Setup:

ScreenHero
Sublime Text 2
shuhari by @jarhart

While we were kicking things off with the “get to know you” talk, I found that Nick had a Rails + Angular.js app he was working on. I’ve not done any work with Angular and asked him to show me what was going on. He pointed out the general structure as well as the custom directives that Angular.js allows you to create. I’ve watched the Ember.js Peepcode Intro, and found it difficult to get excited about it. Being introduced to Angular.js in this particular manner gave me real world applications and it seemed much more intriguing. No verdict yet on either, just initial impressions on both frameworks.

Pairing Post Mortem - @kmeister2000 - Refactoring and MiniTest

Wed, 29 May 2013 00:00:00 +0000

Had a great 4th pairing with @kmeister2000. Always a pleasure to work with him.

Interesting Parts of our session setup:

Worked on a real world app Karl was developing
Used MiniTest instead of RSpec
Refactored existing code

MiniTest Takeaways:

MiniTest expectations about method calls are not as clear as in Rspec and the documentation/examples aren’t as readily available.
MiniTest is a lot like RSpec in nearly every other way.
I’m not a fan of Mocha. I think it promotes antipatterns for how to really test.
I actually like the explicit mock.verify in MiniTest::Spec

General Takeaways:

Pairing Post Mortem : @hinbody - TicTacToe and TMUX

Wed, 29 May 2013 00:00:00 +0000

I just finished my first #pairwithme session with @hinbody. It was my first remote session to use TMUX+VIM instead of ScreenHero – I have to say, it was quite easy to use and given the fact that it’s free, fast, and cross-platform, I’ll be using it with any vim users I pair with who are willing. I’d love to get CoVim working since it allows you to use your own vim setup. I drool a little bit at all that. But I digress.

Pairing Post Mortem : @thecommongeek - Ruby Koans

Tue, 28 May 2013 00:00:00 +0000

I paired with @thecommongeek last night again. This time we were more prepared and I think the session went much better.

In our first session I misjudged where Dennis was as a coder and struggled a bit with how to pair with him effectively. This time we had him drive through ScreenHero and decided to start from the “basics” by doing the RubyKoans.

The RubyKoans are meant for Ruby 1.8.7, but 1.9.3 is commonplace now, so we struggled a bit at the beginning. For anyone going through the RubyKoans on 1.9.3 getting a value19 in nearly all your errors, I’d suggest making the following changes on neo.rb (starting on line 34):

Pairing Post Mortem - @javichitone - Improving a Gem

Wed, 22 May 2013 00:00:00 +0000

I had my first international pairing session with @javichitone tonight. He’s from Peru and will soon be graduating. He should have no trouble finding a job based on the code I got to read of his :)

We talked for a bit and settled into looking at a gem he recently published. Since it was his gem, I elected to drive. I’m familiar enough with gems that I’m comfortable in general, but he knew the specifics of his gem, so to get the most out of it, he needed to be commenting on the specifics he knew and I needed to be diving into figuring out those specifics.

Pairing Post Mortem - @jdar - Chrome Extensions

Tue, 21 May 2013 00:00:00 +0000

Another great pairing session tonight with @jdar! I continue to be amazed at how pleasant and personable the developers I meet are. The internet is a wonderful place.

First up, I’d never coded a Chrome Extension, so Darius took the reigns and started walking through what we were using. The biggest takeaway I got was to put your pride away when you’re pairing. Everyone’s exploring, we’re all trying to get to the next answer, so it doesn’t matter if we’re really well prepared or never coded before… just take the next step.

Pairing Post Mortem - @kmeister2000 - TDD and Domain Knowledge

Thu, 16 May 2013 00:00:00 +0000

Last night I did a #pairwithme session with Karl Meisterheim. He’s an experienced developer who currently work part time and was looking to improve his skills. Besides having a good deal in common and really enjoying our conversation, I also learned a bit more about remote pairing and came away with a couple of observations.

First off, we paired 2 nights in a row for about an hour each night. Both sessions we tried to solve the same problem: TicTacToe. We started off on the second night with the code from the first night, but quickly threw it away and decided to “start over” as an excercise. Doing this taught me the most significant lessons from our session.

Tricks and Tips I've Learned for Coordinating Pairing Sessions

Thu, 16 May 2013 00:00:00 +0000

When I heard about the #pairwithme idea, I thought it was something I really wanted to do. I set aside 3 nights a week from 9-10pm and started pinging people on Twitter during that time, asking if they wanted to pair. I tried for no less than 3 weeks before actually getting a real pairing session going. I had several cancellations and a bunch of fits and starts trying to figure out how to really communicate with people. Here’s my takeaways from the experience of coordinating sessions remotely.

Pairing Post Mortem - @thecommongeek - Learning and Mentoring

Mon, 13 May 2013 00:00:00 +0000

I had a great pairing session with @thecommongeek tonight. It was my first live-remote pair programming and I wanted to to a little “post mortem” on it to record my thoughts.

We spent some time on introductions and then jumped into a problem. Since my box was all set up, I typed. I’m more experienced than Dennis as a coder, so I viewed it as the potential to mentor him a bit. I also learned from him both in the “how to be a better mentor” department and the “how to pair better” department.

Ping Pong Pairing without Screen Sharing

Thu, 09 May 2013 00:00:00 +0000

I often have a bit of time that I could spend on other tasks, but couldn’t set up a true share-and-pair session due to logistics and communication issues. A friend of mine suggested that we “pair” over github. I took the idea to the next level by creating a true ping-pong pairing project where each commit is a ping or a pong.

Here’s the basic setup:

Create a README with the full description of the “task” at hand
Create a github repo and add your ‘pair’ as a collaborator.
Write a failing spec
git commit and git push

Then, each individual takes turns doing the following:

Pairing as a Life Habit

Wed, 24 Apr 2013 00:00:00 +0000

I’m interested in creating a culture of pairing… not just in my workplace, but in my life. I want to be able to pair with people in order to improve on the skills I alread have. This is seen clearly in the relatively new #pairwithme ‘micro-movement’ that is happening on twitter. It shows that people want to learn from each other and improve their craft.

But it doesn’t have to apply solely to programming. Last weekend I “paired” with a neighbor to fix my lawnmower. He is a bit more mechanically inclined than I was, but it took both of our efforts and problem solving to diagnose and fix the problem. All in all, a worthwhile time where I improved both my relationship with Ben and my ability to cut my grass. He got something out of it too, he felt great and is excited to tackle more mechanical projects. This is exactly the same reasons we talk about the benefits pairing in the first place.

TDD and Pairing Ideas

Wed, 24 Apr 2013 00:00:00 +0000

When pairing, especially remotely with someone you don’t work professionally with, it is sometimes helpful to have some ideas about how to go about getting the session going or what to do. This is just a set of ideas that might get the ball rolling.

Problems to work on

PuzzleNode - 15 shortish (30 minutes to 4 hour) problems. Great for pairing.
Conway’s Game of Life - Can implement a basic version quickly. Lots of ideas for restrictions on this site.
TDD Katas - Can be done in 30 minutes alone.
Dominion - A larger problem, but it will tease out larger design issues that you don’t get with smaller systems.
Build a Twitter - Simple system that can be extended. Adding a UI and continuing strict TDD is very interesting since you might be able to TDD the core system, but have more difficulty with the surrounding. Are there ways to mitigate the risks of using a framework as a shell? Are there ways to make the shell “swappable” – not so you’d actually swap, but so you have loose coupling?

Ideas to practice

Ping Pong - Pair back and forth, one writes a failing test, one makes it pass, then writes the next failing test, and so on.
Various Limitations - No loops, no conditionals, limit lines per method, no voice communication (or typing out in chat… only communication is through code)
TDD As If You Mean It - Strict TDD that involves real tests before code and strict refactoring rules. This can be combined with any other limitation or idea, but it’s so difficult (And rewarding) that it’s okay to Just Do This.

Tools

Vim + tmux - how to tmux · tmux basics screencast · Syme · easy ssh/public key auth
Screen Sharing - ScreenHero · Google+ (read only)
Audio - Skype · Google+
Find Pairs - RubyPairs · IRC #pairwithme · Twitter #pairwithme