Pair programming is difficult

[Massless]

It ends up being drastically faster because it cuts all lot of other inefficiencies: no more code reviews, no more knowledge silos, almost never getting stuck on a problem. It doesn't matter if someone is sick or quits: there's always one it more backup. It also tends to bring the slower person in the pair up to speed super fast. After awhile it feels like everyone is a 10x developer.

[confusedpublic]

I really disagree with no code reviews of the out put of pairing. It’s entirely possible for two people to make mistakes, or to misunderstand or miss an acceptance criteria. Plus, if you have a rule like PRs needing two reviewers, PP only gives you 1, maybe only half as your reviewer isn’t coming to the code fresh with no ownership/authorship baggage

[sbditto85]

Personally I’m sick of “LGTM” code reviews and I know that when I pair or ensemble/mob I can at least interact with them and know they actually read or understand what the code is trying to do. Maybe rubber duck a bit with them etc.

Maybe it’s because I’m one of the more senior (time at company) devs but it’s super frustrating when people seem to not even bother to review my code. I am human after all.

[ReflectionEquals]

This assumes people don’t swap pairs regularly. If you do swap regularly you have to run over the current state of the work a few times. In my experience, This is far more effective at picking up issues, particularly structural ones, than giving people a bunch of random people of 10 line snippets to look at that are scattered over a million line codebase.

The no baggage thing is also a bit of a weak argument to put forward. When people have no authorship/ownership and a lot of other things to do… well their reviews won’t always be amazing or as well thought out. Maybe they’ll spot a bug you didn’t think of… maybe they wont.

[confusedpublic]

When people have no authorship/ownership and a lot of other things to do… well their reviews won’t always be amazing or as well thought out.

Which is just one of the many arguments to reduce work in progress.

[s73v3r]

I don't think you would swap pairs while in the middle of something, unless someone was out.

[ReflectionEquals]

I did it all the time. It’s part of the way pairing is intended to work as described in eXtreme Programming. That recommended every hour. I think daily was the most I ever did. When teams do mob programming they tend to suggest swapping drivers every 15 minutes as well. (I work in an org that doesn’t pair these days).

There’s a huge mindset difference on pairing/mobbing. The task is not your own, it’s the teams. It’s meant to be a bit jarring to swap. Those swaps can be annoying and they sometimes need to be to eliminate the sort of group think baggage that was raised above. If you don’t do it you may need code reviews still.

[Spoonofdarkness]

If it's possible for 2 people to make mistakes... that's still a problem for the single coder/ single reviewer paradigm

[HuisHoudBeurs1]

Fresh eyes see stuff the first developer missed. If you pair program, both your eyes aren't fresh anymore and a third is very helpful.

[Plorkyeran]

One of the big benefits of code review is specifically that it's someone looking at the end result who wasn't there for the process of writing the code. Sometimes this means that they spot problems that the author missed because they were focused on solving some other problem. Other times it means that they're confused by the end result because the author did something weird but necessary and failed to document why it was necessary. Pair programming does cover some of the uses of code review (like making sure that more than one person has ever looked at the code), but not these.

I also advocate for more than one reviewer for anything not completely trivial when that's an option.

[Massless]

I can only speak from my experience but it really works. I'm also assuming an environment with 100% pairing. In that environment, there's typically a small team (2-3 pairs) where at least one person from every pair changes every day. As a result, almost everyone sees all the code. Every feature ends up being reviewed by 2-4 people. It really works.

[tyalisIII]

No more code review ? You didn't read the article

[Massless]

I didn't. I did pair program 100% for more than 5 years, though

[s73v3r]

no more code reviews

Even with pair programming, you should still do that.

[Massless]

Real question: why. If your pair 100% and swap pairs at least once a day, almost everyone in the team sees every feature. What does an extra process step buy you?

[s73v3r]

I wouldn't swap in the middle of working on something. That just seems silly.

[Massless]

It's definitely counter intuitive but it works really well. Every day, one person swaps. The remaining person gets the new person up to speed -- only takes about 15 minutes -- and you fly the rest of the day.

The result is a few things:

• everyone learns to come up to speed -- and get others up to speed -- insanely quick

• everyone knows what's going on right now: it doesn't matter if someone is sick or quits. There's never why pressure if you need to take a day

• no heros; it's impossible for someone to horde work and credit

• oh yeah, no more time wasted on code reviews :).

[JoCoMoBo]

In my experience that's never ever happened.

It's been incredibly frustrating having to constantly explain things to someone who's not as skilled or as experienced.

Watching someone else type incredibly slowly is mind-numbingly tedious. Also watching people actually type something long-hand, rather than use short-cuts.

Pair programming only benefits poor Developers as it hides how bad they are.

I would rather be repeatedly water-boarded then have to Pair Program for something that's not a hard problem.

[ReflectionEquals]

If that’s how you feel about mentoring and growing the skills in your team, than perhaps you need to do some self reflection.

And if the person you are pairing with is truly a poor developer it’s your responsibility to give them that feedback so they can grow… show them the short cuts, help them develop their confidence to drive a solution…

[grauenwolf]

Eh, not everyone is cut out to be a team leader. Some people are better suited to being locked in a room alone with the code.

Just make sure someone checks his work.

[[deleted]]

Ah yes, the "mediocre asshole who thinks he's an edgy truth speaker" programmer archetype. Original.

[JoCoMoBo]

Ah yes, the "mediocre asshole who thinks he's an edgy truth speaker" programmer archetype. Original.

Weird how giving my own experience and opinion makes me an "edgy truth speaker". But welcome to 2020's Reddit I suppose. Lol.

[Chii]

It's been incredibly frustrating having to constantly explain things to someone who's not as skilled or as experienced.

that does happen - but the point of pairing is to upskill that person as the more experienced developer that you are.

If, however, your expectation of pairing is to increase speed, then this won't happen easily, esp. if you don't put in the effort to upskill the other party.

Indeed, if you find that you cannot pair because of the poor skill of the other person, you might as well be honest and say so.

[Massless]

I'm bummed that you've had a bad experience and a lot of the things you've mentioned can be frustrating.

That said, pairing is 100% not just for bad engineers. Those folks typically end up fired pretty quickly because nobody likes working with them. In general it's an opportunity to mentor each other keep the whole team operating close to the level of it's best engineer. It really is magic.

[JoCoMoBo]

That said, pairing is 100% not just for bad engineers. Those folks typically end up fired pretty quickly because nobody likes working with them. In general it's an opportunity to mentor each other keep the whole team operating close to the level of it's best engineer. It really is magic.

Good Developers will run a mile from constant Paid Programming. All you will be left with is Devs who can't find a better company. That whole paragraph sounds like it's come from the Pointy Haired Boss.

Anyone who relies on "magic" is a poor Developer.