101–110 of 308 posts
The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.
My experience is that it's best when it happens organically. Enforcing this sounds like a punishment.
There's also the other extreme, Mob Programming, where you get everyone in a room together with one projected screen. The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work. https://mobprogramming.org/
It's powerful, but it's also very expensive, especially if you have several opinionated devs on the team.
I think what would alleviate most of his issues is having frequent breaks. 10 or 30 minutes here and there all day, or even an hour before resyncing is essential. Especially now with remote pairing.
I think opt-in pairing is bad. It essentially means, rarely pair apart from on hard things which is not pairing.
Opt-out is better. Then for some tasks you don't have to pair, whilst for most you do.
Or go full mob programming and allow people to come and go.
Earlier quoted context omitted.
Yes, that's how pairing works: two people, one keyboard, one workstation. Having done this for a while, I wholeheartedly agree with everything the author says. It's great for software quality and productivity (among other things, it's much harder to slack on HN), but it's also incredibly draining and definitely not for everybody.
Two people, TWO keyboards, one workstation (with a good monitor). You can't keep switching seats, or shuttling the keyboard back and forth. Remove as much unnecessary friction as possible. And assign someone on the team to be the tea-mug refiller for the day. And management have to provide a workstation for each worker; you pair at a pairing workstation, but everyone needs their own machine for stuff like email, Slac…
We didn't always bother switching laptops though and we also worked remotely about half the time (using screenhero at the time, I miss SH).
> And assign someone on the team to be the tea-mug refiller for the day.
I disagree with this. I found frequent breaks to be very important. Pairing is exhausting. "Lets get more tea/coffee" was a good way to have a short break. I think frequent breaks also made using different laptops easier, since its natural to switch drivers after a short break. We didn't have breaks on every switch, of course, but on many we did. The breaks were often only a few minutes, but getting away from the screen even for three minutes really helped.
Earlier quoted context omitted.
Two people, TWO keyboards, one workstation (with a good monitor). You can't keep switching seats, or shuttling the keyboard back and forth. Remove as much unnecessary friction as possible. And assign someone on the team to be the tea-mug refiller for the day. And management have to provide a workstation for each worker; you pair at a pairing workstation, but everyone needs their own machine for stuff like email, Slac…
Traditional pairing uses one keyboard, and one screen (or one pair of screens, etc). When i went to Pivotal, that was the first time i had seen two keyboards and mirrored screens. I think the Pivotal way is significantly worse - you have a physical machine to yourself, but not a logical machine, so there is a base level of confusion. Sharing a single keyboard means that it's always obvious who is driving. Sharing a s…
Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…
Opt-in for both sides seems like the best option. You should pair program with someone with whom you get along. Joining a place like Pivotal where you have little control over it and have to pair from the outset with someone you don't know a whole lot about just seems like a bad experiment.
Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…
Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.
Pairing people with the same skill set? Mostly
that’s just a waste.
1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL.
2. Each will know tool/workflow tweaks the other doesn't.
3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer.
To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.
Earlier quoted context omitted.
Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the v…
I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can'…
This story should be in the dictionary under "Cargo cult".
Ding, ding, ding. I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with the inevitable conflict resolution, even if that's not your job. Even if your pair shows only for a couple of hours a day and you have to do the work of two people. “Much harder to spend time on HN” people who like pair programming either like to have power ov…
I sense that you might be saying those phrases can be used to manipulate the other half of the pair. For the first one, I can speculate: The pair disagrees how to approach some problem, then one of the two suggests to “timebox an exploration” into their favorite approach, and then after spending an hour on it (or whatever), the code is already there and nobody wants to delete it again.
But what do the other two phrases even mean, and how would they be used to manipulate?