Mashion's Pairing Rig(matschaffer.com)
matschaffer.com
Mashion's Pairing Rig
http://matschaffer.com/2012/07/mashion-pairing-rig/
12 comments
I wonder how many teams have pair programming engraved into the workflow. As in "for at least a year." I tried it more than once, on different projects with different people and it universally sucked. To say that I hate it with passion is an understatement. Perhaps it was because the language was C or because the routine was instigated by a clueless management, but still... in what conditions does it actually work?
Pair programming is definitely a different skill and takes practice. Because of this I doubt management could ever force it. You'd need people on the team that know how to do it and can help others learn. And if you have those people, they're probably already implementing it.
For me, pairing helps avoid bad decisions before it's too late. There are a lot of choices in programming and when both I and my partner agree on a path it's probably the right one. If we can't agree, usually it's because neither is better than the other.
Also not all tasks are right for pairing. Research for example can be frustrating as a pair activity. This is another reason we like this setup since it gets out of the way for non-pair tasks.
For me, pairing helps avoid bad decisions before it's too late. There are a lot of choices in programming and when both I and my partner agree on a path it's probably the right one. If we can't agree, usually it's because neither is better than the other.
Also not all tasks are right for pairing. Research for example can be frustrating as a pair activity. This is another reason we like this setup since it gets out of the way for non-pair tasks.
> In what conditions does it actually work?
1- Programmer buy-in (preferably grass-roots) rather than management dictate
2- Collective ownership of code
3- Frequent switching of pairing partners (switch multiple times per day)
4- Comfortable pairing stations with no "owner" so people can swap partners and desks easily
5- One shared workspace per project with good noise isolation from other projects
6- Office (or two) with a door for private conversations, phone calls, or when you just need to get away from it all
7- Personal space for each person for pictures, storage, checking email, etc.
8- Sensible working hours (pairing is tiring!)
9- Mature participants without major social hang-ups or hygiene issues
10- Mutual respect
11- Thought-provoking work (TDD & evolutionary design tend to make even boring work thought-provoking)
12- Four to eight weeks to get used to it
1- Programmer buy-in (preferably grass-roots) rather than management dictate
2- Collective ownership of code
3- Frequent switching of pairing partners (switch multiple times per day)
4- Comfortable pairing stations with no "owner" so people can swap partners and desks easily
5- One shared workspace per project with good noise isolation from other projects
6- Office (or two) with a door for private conversations, phone calls, or when you just need to get away from it all
7- Personal space for each person for pictures, storage, checking email, etc.
8- Sensible working hours (pairing is tiring!)
9- Mature participants without major social hang-ups or hygiene issues
10- Mutual respect
11- Thought-provoking work (TDD & evolutionary design tend to make even boring work thought-provoking)
12- Four to eight weeks to get used to it
I've found pairing to be very useful when I don't know the stack or codebase all that well. It can certainly be frustrating though when the two people in the pair have extremely mismatched skill levels and are working against a deadline.
That's not a pair programming though. It's just one person teaching another whatever there needs to be taught.
That is pair programming though. The point is to get the other user up to speed so they can contribute more to the project.
I like to think of knowledge as a resource with compound interest for the individual and especially for the company. Knowledge is built on what you already know and the more you learn the more ideas and knowledge you can generate. Teaching another is the key principle of pairing. If done correctly somebody should always be learning and teaching.
I like to think of knowledge as a resource with compound interest for the individual and especially for the company. Knowledge is built on what you already know and the more you learn the more ideas and knowledge you can generate. Teaching another is the key principle of pairing. If done correctly somebody should always be learning and teaching.
Isn't this the same setup that pivotal has been using for a few years now?
They have a bunch of details in a 2010 blog post here:
http://pivotallabs.com/users/jsusser/blog/articles/1505-pair...
They have a bunch of details in a 2010 blog post here:
http://pivotallabs.com/users/jsusser/blog/articles/1505-pair...
It's pretty close, but it has a few improvements. For starters, the Pivotal setup used Ikea Galant desks, which are a bit large. Instead of needing to cut that in two, we've got two Galant extensions. This eliminates the need for the desk staggering pattern shown in the pivotal post.
Second, the pivotal setup is based around an iMac with a second screen. We've found this somewhat odd as everyone has their own laptop. Therefore, this setup is driven from a laptop with the key addition of an hdmi splitter to make driving two screens from the laptop cost effective.
Second, the pivotal setup is based around an iMac with a second screen. We've found this somewhat odd as everyone has their own laptop. Therefore, this setup is driven from a laptop with the key addition of an hdmi splitter to make driving two screens from the laptop cost effective.
Given the extreme similarities, wouldn't it have been worthwhile to point out the similarities and differences to the Pivotal setup in the article, rather than adding them retroactively in the HN comments?
Very close. That article was the original inspiration and Josh's recent pic (https://twitter.com/joshsusser/status/212928411470012416/pho...) was what helped us realize that the extensions would provide enough space.
Depending on how sensitive you are to peripheral stimuli (which is generally oversensitive thanks to evolution), this setup seems like it'd make you distracted with the movements of your partner's head.