The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.
Utterly ridiculous. I despair sometimes.
Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows.
I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or challenging data problem, I will usually need some alone time with the problem to come up with anything worthwhile. I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output. But that's not always the case! Sometimes it's great having someone to point out lapses in reasoning or suggest approaches I wouldn't have thought of, or to be that person for someone else.
Anyway, I only thought to mention that because the angles given in TFA were so disappointing and also because I have seen some job ads that mention something to the effect that all programming that happens in that shop is pair-programming, and while I love pair-programming, that sounds like a special kind of hell I would love very much to avoid.
But then, I've never worked in such a shop -- maybe it's great, even if it's probably not for me?
Early in my career - in a 4 person shop - I had a manager that mandated it. He was very extroverted and always talking. Pair programming was very difficult for me because my attention always shifted to him and any complex thoughts about the code would be wiped clean from my mind as he went off into some ridiculous rant. The conversations that weren't about random stuff usually went like this:
"Are you watching?" "Yes" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Yes I did" "..."
He gave up after a while, thankfully. Pair programming is definitely not for me. But I'd love to work in shared IDE on different parts of the code. That seems fun - as long as there isn't a lot of talking.
I'm happy to do it occasionally to transfer knowledge, but it slows me down massively because it totally changes my thought processes when I'm constantly aware of another person there with me.
I wonder how significant the effect of mandating it is on the personalities you're able to hire. Many of my by far most productive developers have been introverts like me who'd likely not to consider jobs in those kinds of environments.
You can pretend it’s a magical experience where all parties are teaching and learning and having a wonderful time.
In the real world it’s an inconvenience where one person invades your personal space, hovers over your shoulder on your desk with no space as you awkwardly work through who knows what and establish a pattern of dominance as one person clearly knows more than the other and will just do the work themselves while the other watches OR question every single thing typed to the bemused person at the keyboard. No personal bonds are formed during this intrusive process.
I don't understand your point. In a world where most developers are almost certainly gone in a couple of years, programmer velocity seems to me to be more important than getting people to understand lots of parts of the code base (once they understand 2 or 3 big chunks of it they'll be probably gone)... and to get to understand a small part of the whole it only takes a few sessions of either pair programming or, better, design sessions.
I may sound like someone who's given up on "sharing knowledge" and just cares about output... and you'd be right. Because that's the world I live in, not the world I would like to live in...
I've been in the same company for 6 years now. Got a 25% raise recently because they don't want me to leave (they were damn right I would leave soon otherwise)... in this time, I've seen many come and go... spending time teaching them more than they need to accomplish the work they need to do in the next few months is what I would call a total waste of my time... I show them what they need to see, then leave them to their own devices. Most of them are smart enough to get stuff done after just a couple of design clarifications... If I had to sit all day with them trying to explain how everything works everytime we made a change our output would go down 90% and we would be out of business in a few years.
There’s an argument that “teaching and learning from each other” produces more economic value in the long run, but you reach diminishing returns pretty quickly on that.
And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome.
You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it).
PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it).
I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.
The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them.
It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.
> While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.
It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick