I’d agree except for the I-will-interrupt-the-next-dude (chick) when I’m finished my story to pair part. Make it known that you’re available to pair if needed, but pairing as SOP would have me interviewing.
Pairing is very much a cultural thing. It's either normal or it's not. If it's not it tends to only be a "ask me for help if needed", which leads to not doing it. That's not really pairing either, that's just "Let me know if anybody needs any help."
The perks of pairing are regularly unsticking stuck people, getting another set of eyes on a problem, learning from each others development habits as a side effect of doing your job. People tend to really overthink what is involved in pairing, turning it into some rigidly drilled type of exercise.
All that is needed to get most of the benefits is to fire up a screen share and verbally communicate while the main developer keeps working. Everything else falls into place. Even if it's just for a couple of hours here and there rather than "finish this entire story with this person" it's beneficial.
When people get stuck on something, it can become harder for them to focus. They'll start looking for alternatives like opening HN or Facebook, reading an article, etc. For a lot of people trying to prove themselves, asking for help isn't going to happen until it's too late and that makes it easy for people to work in their own little bubble.
If it's considered an interruption for you to screen share while the person continues to code, you're doing pairing wrong.
That's the thing...it's the typical response because it's true...
If pairing periodically is enough of a burden on you that it would cause you to interview elsewhere, it really seems like you're overthinking the impact.
You’re being dogmatic. Assuming that something works for everyone because it works for you, and if they say it doesn’t, it’s because they “don’t understand,” is wholly closed-minded.
I have to ask...what is your expectation of working on a development team? How do you feel team members should learn from each other? What process would you use to help get junior developers up to speed faster?
These are the questions that periodic pairing answers with the lowest possible negative impact to members time.
Now, if you get into an environment that is 100% pairing all the time, or two people at the keyboard taking turns with an egg timer, etc...that can be a huge pain and I'd totally understand not wanting any part of it.
Watching somebody code while you drink a cup of coffee at your desk and offering the occasional "you know, if you do such-n-such it will be a little cleaner" or "I think there's a function that already does what you're writing"...is pretty low-impact.
EDIT: I read through your comment history and see that you were with Pivotal. IIRC they are a pairing all the time shop (I seem to remember seeing a presentation at some point). I can completely understand how that would suck.
The perks of pairing are regularly unsticking stuck people, getting another set of eyes on a problem, learning from each others development habits as a side effect of doing your job. People tend to really overthink what is involved in pairing, turning it into some rigidly drilled type of exercise.
All that is needed to get most of the benefits is to fire up a screen share and verbally communicate while the main developer keeps working. Everything else falls into place. Even if it's just for a couple of hours here and there rather than "finish this entire story with this person" it's beneficial.
When people get stuck on something, it can become harder for them to focus. They'll start looking for alternatives like opening HN or Facebook, reading an article, etc. For a lot of people trying to prove themselves, asking for help isn't going to happen until it's too late and that makes it easy for people to work in their own little bubble.
If it's considered an interruption for you to screen share while the person continues to code, you're doing pairing wrong.