“I’ve done ‘pairing,’ but it wasn’t for me: I like my editor. I like my space. I don’t like to talk all the time… you know.” We’ve all had our reasons. And, I will admit that it works for some and not for others, and it works better in some situations and not in others. But, what if my “bad experience” is a fluke of “how” it’s being done?
What should you expect from a good pair? How do you handle timezones? System configurations? And, what tools should you use to make the experience optimal?
There’s a lot of opinion about pair programming, but we’re going go over what to expect from pairing, and when it’s the “right time” to use it.
The function of this talk is not a case in favor of pair-programming (although that may be a take away). The structure of the talk is to address patterns for effective pair programming; there is an effective “how.”
The talk is structured into two parts:
The What’s Its
How’s Its
Our consultancy is advised by Kent Beck, so the topic is near to us. We’ve discussed on occasions the merits of pair programming.
Kent told us, “You know, most people read the last half of my book on eXtreme Programming – the part about the tools – and they get attached to pair programming, TDD and iterations, but miss the reasons why you do it, at all.”
Not too long ago, we decided to take a step back and ask “why are we doing it?” and found that certain aspects of pairing, like TDD, are important, and other’s aren’t.
We’ve experimented with full time pairing, soloing and everything in between. We’ve tested rigid schedules and total freedom. We’ve worked across time zones, local and remote and VIM/TMUX against Screenhero, Skype and Google Hangout.
We haven’t tried everything, but we’ve tried a lot of things.
This talk is not going to force the issue, but introduce the methodologies we’ve used to maximize the value of pair programming. It’s a very balanced approach to the subject.
SD Ruby 2015 - Accepted [Edit]
Brighton Ruby 2016 - Rejected [Edit]
Abstractions 2016 - Waitlisted [Edit]
Add submission