[jamghee]

I working in XP for a bit and the constant pair programming aspect was simply too fatiguing for me. I enjoy pairing every now and then on certain problems, but the constant presence of another person left me utterly drained at the end of every day.

[scrapheap]

I know some people really work well when pair programming, but I find that I either slip into Student Mode or Teacher Mode when I try it. Either the other person knows the environment we're working in (architecture, codebase, etc) a lot better than I do, and I'm using the session to gather as much information as I can, or I know the environment better and so I'm explaining why I'm doing things.

If the other person and I are on par with the environment then we're more likely to have a discussion about what we're wanting to achieve and how best to go about it, but then one of us will go away and knock out a first cut for the other person to review.

I do wonder what differs between groups of people who can actually do pair programming and those that (like me) that can't.

[JackMorgan]

I think slipping into student mode or teacher mode is a fantastic reason to pair: it's full time training. You quickly will all rise to the skill level of the best parts of every engineer on the team. Otherwise training is rare and slow.

[pydry]

My mode is either driving and listening to advice or watching and trying to spot things the driver missed.

Occasionally I do side-work if Im not driving - e.g. look something up, message devops, a very small PR etc. so the driver can maintain focus.

I find it to be much more effective that working alone simply because so much stuff that would take me 20 minutes to to go down a rabbit hole ends up being caught by an extra pair of eyes in 4 seconds.

[j4yav]

I always thought that student / teacher mode was the very best form of pair programming.

[kstenerud]

Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto)

But the article highlights the good points of agile, and I agree with them:

- Iterative development (smaller steps with faster feedback)

- Unit tests (and building with unit tests in mind)

- Code Refactoring (which you can do confidently when you have unit tests)

The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV

[azangru]

> if you don't do it entirely this way, you're not extreme programming

But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming.

It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.

[michaelcampbell]

> This is the way to do things, and if you don't do it entirely this way, you're not extreme programming!

Which is fine. They defined a set of practices, called it XP, and if you don't do these, you're not doing XP.

[somewhereoutth]

Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.

[willsmith72]

I actually loved it. I had never learned so much or shipped so quickly and reliably.

And then I moved teams... And realised it's all about the people and culture around you.

I probably wouldn't sign up for it again when joining a new company, because at its worst it's absolute torture, but I still believe that at its best there's nothing like it.

[michaelcampbell]

You both can be right. It can be the best way for you, and it can also be utterly exhausting for them.

Personally, I'm not willing to get rid of _all_ my comfort zone to get something out the door more efficiently, where shareholders and C-levels get rich off my labor, and if I'm very lucky, I get to keep doing that.

[crabbone]

If I had to pair-program, I'd probably call in sick. And if this was a repeated demand, I'd eventually just quit.

To me, this is one of the worst ways to work. I very much prefer to communicate in writing, and at prearranged times. To me, the idea that there's another person working with me on the same problem at the same time is as absurd as having another person cooking in the same kitchen with me, or painting on the same canvas as me. Whatever result I can produce on my own, it will be ten times worse if I had to do it with someone else working on the same problem with me.

[pjmlp]

Same here, just the idea of forced XP is enough for me to start considering other positions.

[gramie]

I went through a period of a couple of months where I pair-programmed almost every day, and it was probably the most productive time of my career. My partner was very junior, and new to the project, and the process of explaining things to him definitely helped avoid some of my blind spots. He had several good insights and ideas, too, coming in with fresh eyes.

It was high-energy, though, and an extended period might well have been fatiguing.

[djtango]

first, there's a definitely a stamina to it - I worked in an XP team for best part of 3 years and have at other jobs done a lot of full-time pairing (sometimes months at a time).

Second, there's a chemistry element. When there's good chemistry it can be quite effortless and the chemistry can grow - as you start to develop an intuition for how the other person thinks there's less communication and mental jostling.

I've had remote pairing sessions that have felt almost as fun as online gaming.