11–20 of 82 posts
Pair programming can be very useful when you're training someone new or starting up a new project and want to spitball ideas. I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.
At my current job I pair maybe 2 or 3 hours a week, and for my working style that's perfect.
Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere. So, the cost of losing one or both of the programmers in the process must be considered too.
I don’t know if I would say I “hate” it, but the one time I tried it (at the behest of my then-employer), I and the rest of my team found it to be unworkably impractical. We had half as many computers as we had programmers, so we each shared a workstation. However, each of us had our own individual e-mail addresses, so we’d have to take turns checking and reading e-mail while the other one sort of looked away. When w…
If you're pairing, don't read your e-mail. Even if you're just in a solo work session, don't read your e-mail. It's incredibly disruptive and constant inbox checking will drop your productivity like a rock.
It's okay to pair with multiple workstations (or a single workstation set up for multi-user mode, that's the dream I guess). Looking away from the "main screen" to check docs (or VCS, or the build, etc.) is perfectly fine, just don't get drawn in so deep that you forget about your partner. And certainly don't use that as an excuse to check your e-mail or slack!
One strategy to apply is "show, don't tell". If you have a hard time explaining what you're going to try to do, just do it, the code will probably be clearer than your explanation alone. If it's not, use the conversation to drive the uncovering of assumptions, which can then be encoded in the source.
Remember that pairing isn't simply two people, one keyboard. There are defined roles: the driver and the navigator. The driver handles mechanics, the navigator observes and questions assumptions. Then switch roles. The driver should fearlessly try the experimental things. If the navigator wants to experiment, ask to drive.
Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed. Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"
However, for short bursts (10minutes to max about 90) that are focused on a particular goal makes me feel both re-invigorated and more satisfied with the completeness of the ideas.
The re-invigoratation (for me) comes from not having to run my brain at 100% for the duration. In auto racing terms, my partner and I can take turns drafting off each other’s thoughts, increasing our mental efficiency.
When differences arise I love hearing their thoughts and finding ways to merge the best of both ideas- or completely tossing my own because theirs are better. I’ve heard it (no clue where or from whom) described as idea sex. I’m very okay with my ideas being promiscuous and having lots of better little idea babies.
I still haven’t figured out how to keep my skin from crawling watching people fumble around their UIs though...
Pair programming can be very useful when you're training someone new or starting up a new project and want to spitball ideas. I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.
Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed. Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"
my favorite time in college was the one time I met a similarly minded guy, we cracked through problems with such a positive energy. It was like a biking race, I'd find an idea, then get stuck, he'd try something, so on and so forth.
Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.
I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.
It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.