The Pros & Cons Of Pair Programming (With Examples)

Pair programming is one of the most extreme, yet most valuable, practices in Extreme Programming (XP). In this episode Dave Farley breaks down the pros and cons of pair programming, sharing insights from over four decades of experience working in professional software teams. We explore why so many developers resist pair programming at first, only to love it once they’ve tried it. Does pair programming slow you down, or does it actually make teams more productive? What does the data say about remote pair programming? And how does pairing lead to better software, cleaner code, and stronger development teams? Whether you’re a seasoned software engineer or a new developer, this episode is packed with practical insights into how pairing improves code quality, developer collaboration, and team culture.
In addition to Dave’s perspective, we show you a real-world pair programming session, demonstrating how two developers work together to refactor bad code, strategize solutions, and improve design. This is a hands-on pair programming tutorial that will give you a clear idea of how pairing actually works in practice, whether you code in Java, Python, C#, or any other language. Plus, we discuss the role of remote pair programming tools like Tuple, and why the best development teams use pairing to drive higher quality software engineering. If you’re serious about modern software engineering and developer best practices, this is an episode you don’t want to miss!
-
Try Tuple for your Pair Programming needs ➡️ tuple.app/cdpair
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! ➡️ bit.ly/Continu...
🎥 Join Us On TikTok ➡️ / modern.s.engineering
-
CHANNEL SPONSORS:
Tuple is a remote ensemble and pair programming app for macOS and Windows, designed to make you feel like you're collaborating in person. It’s got loads of developer-specific touches you just don’t see with generic screen-sharing tools. Check out Tuple HERE ➡️ tuple.app/cdpair
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
Honeycomb is the observability platform that enables engineering teams to find and solve problems they couldn’t before. Query everything at once, fast enough to keep your train of thought, and connect your whole system and your teams ➡️ bit.ly/CDHC
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3Uby9iA
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🖇️ LINKS:
🔗 “Pair Programming Increases ‘Flow’” ➡️ journals.sagep...
🔗 "What Makes Teams High Performers?" ➡️ rework.withgoo...
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 "Extreme Programming Explained: Embrace Change", Kent Beck ➡️ amzn.to/3K5fhg6
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
#software #softwareengineering #developer #programming #code

[@ContinuousDelivery]

Try Tuple for your Pair Programming needs ➡ tuple.app/cd

[@DoubleFaceReal]

Pair programming is the best way to go! I think also code reviews are usefull in the same way, it just happen that sometimes if the crap is too much you better start off again, its up to the leaders assigning small reviwable tasks.

[@Jollyprez]

REALLY depends on the person you're paired-with, and context. I've been on three types - as junior / inexperienced in particular subsystem - senior / mentor, and both even, trying to figure something out. The only NEGATIVE ( truly negative ) experience was as the inexperienced person with the impatient / condescending principal engineer. If you didn't instantly catch a point, he ridiculed you and questioned your competence. Luckily, I don't have to work with him any more. The "even" event I'm thinking of was when three of us senior engineers were attempting to decipher some javascript code and none of us could follow it. It had a bug, and the guy that wrote it was unavailable for consultation. I rewrote the section - fixing the bug - and it went into production with no problems. Several weeks later, the original engineer removed my fix, and put-in his own fix. His fix DID work, but it was already working - that's teamwork?

[@PaulSebastianM]

Finally something to show to those pesky managers that don't wanna believe you that pair programming works wonders.

[@MohamedSamyAlRabbani]

I am surprised that the open source dev teams for projects like the Linux Kernel which we know are high performance teams are not studied or looked to for best practices, even though they have been highly performing and working remote since the early days of the internet

[@danieleluppi6648]

your videos are becoming a great habit for my evenings.. wanna a 4 hrs interview with uncle

[@StreetsOfBoston]

Dave, at 20:51, did you say "Prayer Programming"? 😀🤣 Folks who don't like pair-programming will probably love that (Freudian) slip.

[@Efecretion]

The bet type of programming is prayer programming!!

[@blaiseutube]

It is a pity you didn't mention ensemble (mob) programming, which is meant to solve a different set of concerns but also involves multiple people.

[@xlerb2286]

I loved pair programming. Every time we had a nasty problem we'd get a couple smart folks on it and things would happen. We had to be a little stealthy about it as the head of development wasn't a fan of pair programming. I also spent about 10 years doing semi-pair programming. I worked with another dev in an area that had a lot of overlap and we'd spend a lot of time discussing the upcoming features, brainstorming how to approach them, that sort of thing. Then we'd each go do our thing, until we had a bright idea or some issue. Then go back into a huddle to sort it through. That may involve doing a prototype, pair programming, or sometimes even scrapping the approach and starting over.

[@StdDev99]

That doesn't work for all industries. We don't often write thousands of lines at once. Usually it's a teeny tiny change somewhere that's very tricky to find. Surrounded with lots of testing, strategizing, and verification. There's no point getting two people doing that tiny change together. It's the testing and getting measurements that could be done in pairs.

[@MohamedSamyAlRabbani]

I think the most important caveat is, the pair need to be close in skill, and it doesn't have to be all the time, and some people think better alone, and both have to be engaged, meaning one has to be typing while the other drives and vice versa or you just have one person watching the other work.

[@Hofer2304]

If you are typing, you are the driver, the other is the observer. Everyone thinks better alone, so the task of the observer is not to check if they would have written the same code, but to tell the driver there is a missing test, or any other small bug. Treat your partner respectfully. You have to practice pair programming. You could start with a simple hello-world -program and then send the message send to a remote screen. Can you check the availability of this screen? Error messages and warnings must not appear on a public screen.

[@boganlegolas5562]

Great discussion of an important topic!

[@StreetsOfBoston]

The mention of the small amount but horrible code at 16:01 reminds me of a joke, which originally is related to "food", but rewriting it here for "code": Pair Programmer 1: "The code here is h.o.r.r.i.b.l.e." Pair Programmer 2: "Yeah! Not only that, but the amounts of it are so SMALL!" ;-p

[@BestHKisDLM]

I love pair programming. But I hate it with a vengeance when I have to do it and navigate one of our severly overpaid and academically highly accomplished colleague who seems to suffer from “left hands” ANYTIME he is the one tasked with anything, or he even volunteer to take the story… It’s the most frustrating experience for me and many of my peers. The lack of proper vocabulary combined with sheer incompetence in development practices after he reclaimed send PhD and is with company for 3 years… most annoying really is the “memory loss and cluelessness” if we try to combine more than two-three simple steps… with us trying to desperately avoid programming by remote control… occasional mob sessions when he is driver, as he is totally incapable on navigating, believe me we tried hard, ends after initial 15 minutes a slack feed full of “stay calm” or similar quotes and gifs.

[@rj7855]

I hate done plenty of pair programing and i still hate it

[@HobbyHalloween]

Well, you're preaching to the choir, sir... but being a developer that has tried to introduce this approach to management. It's a big no-go for them. And if you try to consult with your coworkers, they'll write you up for interrupting other developers and accuse you for not being able to think for yourself. So after a few poor performance reviews like that, F that, just put your head down and stay in your silo.

[@adambickford8720]

What dogmatic BS. Saying always is as naive as saying never. The bottom line is coming to consensus always takes longer than not but doesn't always add value. Certainly, it does some of the time, which is when we should pair. Breaking up and coordinating the work is an overhead working alone doesn't require. Sometimes it's worth it, sometimes the coordination is almost as much effort as the work.

[@musicman49]

Unintentional irony?

[@leonardschoyen]

The fact that two people have come to a consensus is always great value because it guarantees a certain understandability. That understandability is nice not only when other people are reading the code later but also when the original authors come back to the code after say two months. The work that a pair of programmers would tackle are the same unit as a solo developer, so there isn't more work breaking down pieces of work for pairs than for solo. The coordination overhead is a trade-off for having two people look at the idea being developed at what might be the best possible time - right before implementation. Another set of eyes looking at the concept to be implemented later, like during a PR, is too late.

[@dinov5347]

How do you handle programmers with bad hygiene and halitosis?

[@georgemdonnelly]

so much time and friction during pr review - wonder if good pair programming can help that out plus reduce team tension.

[@SirBenJamin_]

I was on board until you showed your example 😅😅 lots of waffle