To Pair or Not to Pair: Pair Programming

Summary

The speaker from ThoughtWorks in Berlin discusses pair programming, an agile practice where two developers collaborate at one computer. Despite its benefits like knowledge sharing, reduced errors, and increased code quality, pair programming faces challenges due to its intensity and personal nature. The talk aims to inspire both skeptics and advocates, offering insights on overcoming obstacles and leveraging pair programming for better team performance and collaboration.

Takeaways

• 🌟 Pair programming is an agile development practice where two developers work together at one computer to create code, which can increase productivity and code quality.
• 📚 The concept dates back to the 1940s with the first programmers, Jean Bartik and Betty Snyder, who believed in the effectiveness of pair work for programming.
• 🔧 Pair programming is considered a core practice at ThoughtWorks, a global software consultancy, for its contribution to successful software development.
• 💡 Despite its benefits, pair programming has patchy adoption across the industry, partly due to misconceptions about reduced productivity and the difficulty of implementation.
• 🤝 The practice enhances knowledge sharing, allows for different thinking modes, and encourages reflection on the code and its value, potentially reducing the amount of future maintenance required.
• 🧘‍♂️ Pairing helps developers maintain focus, avoid 'rabbit holes' in problem-solving, and integrate code more frequently, leading to better team flow and quality delivery.
• 🔄 True continuous integration is facilitated by pair programming, with on-the-go code reviews and collective code ownership, which are essential for trunk-based development.
• 🚫 Pair programming can be challenging due to its intensity and the need for effective collaboration, including giving and receiving feedback, and managing personal work styles.
• 🔄 The practice requires vulnerability and openness to criticism, which can be difficult but is essential for personal and team growth in a safe and positive team environment.
• 🛠️ Pair programming can be made more effective by improving various skills such as concentration, task organization, time management, communication, and empathy.
• 🌈 Embracing diversity and the friction it can initially cause is crucial for high-performing teams, and pair programming can help in developing the necessary tools to handle this friction.
• 🎉 The talk concludes with the idea that pair programming is not just a development technique but a skill that contributes to better collaboration and team performance, despite the initial challenges.

Q & A

What is pair programming and why is it significant in software development?

Pair programming is an agile development practice where two developers work together on the same task, sitting in front of a single computer. It is significant because it encourages knowledge sharing, reduces errors, and enhances code quality, leading to more effective and maintainable software development.

Why was pair programming not widely adopted initially, according to the speaker?

The speaker suggests that pair programming was not widely adopted initially because it is a long-term game with medium to long-term benefits such as consistent quality and maintainability, which are hard to measure. Additionally, it requires a shift in mindset from short-term gratification to long-term productivity and effectiveness.

What are some of the core values and practices that ThoughtWorks considers crucial for successful software delivery?

ThoughtWorks considers several core values and practices crucial for successful software delivery, including pair programming, which they see as a core practice that enhances the effectiveness of software development.

What are some of the benefits of pair programming mentioned in the script?

Some benefits of pair programming mentioned include knowledge sharing, combining two modes of thinking, increased focus, practicing true continuous integration, and reducing the number of lines of code that need to be maintained in the future.

How does pair programming contribute to the concept of 'one plus one is greater than two'?

Pair programming contributes to the concept of 'one plus one is greater than two' by allowing for the sharing of knowledge, the combination of different modes of thinking, and the reflection on the code and its value. This collaborative approach can lead to better outcomes than what one person could achieve alone.

What are some challenges that the speaker identifies with pair programming?

The speaker identifies challenges such as the intensity of collaboration, the potential for exhaustion, the need for effective communication and feedback, and the personal nature of sharing a workspace and ideas.

Why is it important to avoid pairing for eight hours a day according to the script?

It is important to avoid pairing for eight hours a day because it can be energy draining and overwhelming. It's recommended to find a balance, take breaks, and incorporate other tasks and activities that are part of the development process.

How can pair programming help with the practice of continuous integration?

Pair programming helps with continuous integration by providing on-the-go code reviews and fostering collective code ownership. This leads to more frequent integration and reduces the risk of merge conflicts and technical debt.

What is the role of vulnerability in pair programming, as discussed in the script?

Vulnerability plays a significant role in pair programming as it involves sharing what one knows and does not know, exposing one's strengths and weaknesses. This openness to criticism and learning from each other is crucial for the success of pair programming.

How does the speaker suggest dealing with the friction and conflict that can arise from pair programming?

The speaker suggests dealing with friction and conflict by practicing feedback, improving communication, fostering a sense of psychological safety, and promoting humility and empathy within the team.

What is the significance of the ENIAC women in the context of pair programming?

The ENIAC women, Jean Bartik and Betty Snyder, are significant because they were among the first programmers and naturally adopted pair programming as their method of work. Their experience highlights the historical roots and effectiveness of pair programming in software development.

Outlines

00:00

👥 Introduction to Pair Programming

The speaker introduces the concept of pair programming, a collaborative software development practice where two programmers work together at one workstation. The speaker, based in Berlin and working for ThoughtWorks, aims to inspire those unfamiliar or skeptical about pair programming and to provide insights for those who are already practicing it. The speaker traces the roots of pair programming back to the first programmers in the 1940s, highlighting the ENIAC women and their approach to problem-solving. Despite being a well-known agile development practice, pair programming still faces challenges in adoption across the industry.

05:01

🤝 Benefits and Challenges of Pair Programming

This paragraph delves into the benefits of pair programming, such as knowledge sharing, combining different thinking modes, and fostering reflection on code and project value. It also addresses the challenges, including the misconception that pair programming halves developer productivity. The speaker emphasizes that pair programming is about increasing effectiveness and maintainability in the medium to long term, rather than just the quantity of code produced. The speaker also discusses the difficulty of implementing pair programming due to its intensive collaborative nature and the need for a supportive team environment.

10:03

🔄 Overcoming Pair Programming Hurdles

The speaker discusses strategies to overcome the difficulties associated with pair programming, such as avoiding exhaustion by not pairing for the entire workday and ensuring regular breaks. Time management techniques like Pomodoro can be beneficial. The speaker also emphasizes the importance of feedback, understanding each other's work preferences, and being aware of personal differences that can affect the pairing experience. The paragraph also touches on the personal nature of pair programming, which can expose vulnerabilities and require a high level of trust and safety within the team.

15:04

🌟 Embracing Friction for High Performance

In the final paragraph, the speaker argues that the friction and discomfort experienced during the initial stages of implementing pair programming can ultimately lead to higher team performance. The speaker references the fluency heuristic, which suggests that we prefer things that are easy to process, but this bias can hinder the adoption of beneficial practices like pair programming. The speaker concludes by encouraging the audience to view pair programming as a skill that can be developed and to embrace the challenges as part of becoming a high-performing, diverse team.

Keywords

💡Pair Programming

Pair programming is an agile development practice where two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it's written in real-time. The concept is central to the video's theme, emphasizing collaboration, knowledge sharing, and increased productivity. The script mentions pair programming as a core practice at ThoughtWorks and discusses its benefits and challenges.

💡Agile Development

Agile development is a project management and product development approach that emphasizes flexibility, collaboration, and customer feedback. It is the overarching methodology within which pair programming operates, as highlighted by the speaker's mention of pair programming as an 'agile development practice.' The video discusses how pair programming fits into the agile framework and its impact on software development.

💡Knowledge Sharing

Knowledge sharing refers to the process of exchanging information, skills, and insights among team members. In the context of pair programming, it is a key benefit, allowing for the combination of different perspectives and expertise to enhance the quality of the code. The script illustrates this with the idea that pair programming can lead to better programs and designs through mutual criticism and idea sharing.

💡ENIAC Women

The ENIAC Women were the first programmers of the ENIAC computer, which is considered one of the first general-purpose electronic computers. They are mentioned in the script as pioneers of pair programming, with Jean Bartik and Betty Snyder working together as a pair, emphasizing the historical roots of collaborative programming practices.

💡Continuous Integration

Continuous integration is a software development practice where developers frequently merge their code changes into a central repository, leading to more reliable and stable software builds. The script discusses how pair programming facilitates true continuous integration by providing on-the-go code review and collective code ownership, which are essential for maintaining code quality.

💡Productivity

Productivity in the context of pair programming is not just about the number of lines of code written but also the effectiveness and efficiency of the work. The speaker challenges the misconception that pair programming halves developer productivity, arguing instead that it enhances productivity and effectiveness through shared knowledge and immediate feedback.

💡Code Review

Code review is the process of examining code to detect errors, vulnerabilities, or suboptimal code segments. In pair programming, code review happens on the go, as one developer writes the code and the other reviews it in real-time. The script contrasts this with post-hoc code reviews, highlighting the benefits of immediate feedback and reduced integration issues.

💡Feedback

Feedback in pair programming is a crucial aspect of the practice, where developers provide immediate and constructive criticism to each other. The script discusses the importance of giving and receiving feedback as a way to improve collaboration and the quality of the code, as well as a skill that can be developed and applied in other areas of teamwork.

💡Vulnerability

Vulnerability in pair programming refers to the openness to share one's knowledge and lack thereof with a partner. The script touches on the emotional aspect of pair programming, where developers must be willing to expose their weaknesses and learn from each other, which can be challenging but ultimately leads to stronger team dynamics.

💡Diversity

Diversity in the context of the video refers to the variety of backgrounds, perspectives, and experiences within a team. The script suggests that while diversity can initially increase friction, it ultimately leads to better team performance. It also notes that diversity can pose additional challenges in pair programming, particularly for those from under-represented groups.

💡Psychological Safety

Psychological safety is the feeling of being able to take risks without fear of negative consequences within a team. The script mentions the importance of creating a positive and safe team environment for pair programming to thrive, where developers feel comfortable being vulnerable and providing constructive feedback.

Highlights

Pair programming is an agile development practice involving two developers working together at one computer.

Despite being well-known, pair programming has patchy adoption across the industry.

Jean Bartik, one of the first programmers, advocated for pair programming in the 1940s for better programs and designs.

Pair programming became more widely recognized in the late 90s through Kent Beck's Extreme Programming practices.

ThoughtWorks considers pair programming a core practice for successful software development.

Pair programming faces resistance due to misconceptions about reduced developer productivity.

The effectiveness of pair programming extends beyond the number of lines of code written.

Pair programming facilitates knowledge sharing and code ownership across the team.

It enables combining different modes of thinking, with one person focusing on details and the other on the bigger picture.

Pairing encourages reflection on code and its value, potentially reducing unnecessary lines of code.

Pair programming helps developers maintain focus and avoid 'rabbit holes' in problem-solving.

Implementing pair programming can improve team flow and the ability to deliver high-quality work.

True continuous integration is practiced through pair programming, with on-the-go code reviews and collective code ownership.

Pair programming can be challenging due to its intensity and the need for effective collaboration.

It requires vulnerability and openness to criticism, which can be difficult for some developers.

Pair programming is most successful in a positive and safe team environment that values everyone's contributions.

Diversity, like pair programming, can initially increase friction but ultimately improves team performance.

Pair programming is not just about coding together but also about improving collaboration and communication skills.

Despite initial challenges, pair programming is often found to be fun and rewarding by developers.

Transcripts

I'm actually based out of Berlin.

I work for ThoughtWorks in Berlin.

And I want to talk to you today about pair programming,

so the practice of two people creating code together sitting

in front of a computer.

And it's an agile development practice

that I think is generally quite well-known,

but actually still has patchy adoption across the industry,

I would say.

And for those of you who are not convinced

that it's really useful, or maybe only use it irregularly,

I hope to give you some new inspiration

to maybe try it or try it again.

And those of you who are regular pairers or maybe even

passionate advocates, maybe I can give you some new ideas

and help you convince other people to try it.

And I'll actually start at the very beginning, in the 1940s,

with the first programmers.

So on this picture, you can see Jean Bartik and Betty Snyder

in front of the ENIAC computer, which

is by many considered to be one of the very

first electronic computers.

And the ENIAC women are the first programmers.

So they had to figure out what to do

and how to do it effectively before the word

"programming" even existed.

And this is a quote from a 2011 interview with Jean Bartik.

And she says here that, "Betty Snyder and I,

from the beginning, were a pair.

And I believe that the best programs and designs

are done by pairs because you can criticize each other,

find each other's errors, and use the best ideas."

And when I saw this interview, first, it

blew my mind a little bit.

Because here were these very first programmers

who didn't have any role models to tell them how to do this.

And they came to the conclusion that it would be useful if they

worked on this as a pair.

So fast forward 50 years later, so it

took us 50 years for pair programming

to become a more widely-spread term.

When Kent Beck described it in the late 90s

as one of the practices under the label Extreme Programming.

And at ThoughtWorks, we're a consultancy.

So each situation we get into, we

tune the practices, approaches, technologies

that we need to use.

However, there are a few core values and practices

that we see as crucial to successful and sustainable

software delivery.

And our colleague Evan Bottcher wrote

about this set of core values and practices

last year on our company blog, ThoughtWorks Insights.

And pair programming is one of those core practices

that we as a group generally agree on

that it's really at the core of successful software

development.

But there's still lots of discussion on the details,

as you can see from some of the subject

lines I pulled out from our most vibrant internal mailing list.

And a vast majority of the clients that we work with

have often not had pair programming

as a common practice when we get there.

And also, on average, they often resist to it much more than

to some of the other practices like test-driven development.

As you can see, some of us are struggling

with this from these other subjects

here, like client wants to stop pair programming.

What should we do?

Also, most of the applicants for a developer

job with ThoughtWorks in Germany, at least, I see,

have not had much prior experience

with pair programming.

Same for me when I started five years ago.

I hadn't actually done it that much.

So why is it not more widely adopted?

I think there are two main reasons.

The first one is that it's a long game.

So you can see short-term benefits,

like less errors, less rework.

But ultimately, for me, it's about

medium to long-term consistent quality and maintainability.

And as developers, we like the short-term gratification

of seeing something work today, immediately, right?

And that's actually something, maybe one of the things

we share with project managers.

And for them, pair programming also feels counter-intuitive.

Doesn't it halve the productivity of developers?

And Martin actually said in 2006-- actually 12 years ago,

in this blog post--

that his flippant answer to that one is,

"That would be true if the hardest part of programming

was typing."

So it's actually not about the number of lines of code, right?

It's about productivity and effectiveness,

and those two things are very hard to measure.

The second reason why I think it's not

as widely adopted as maybe it should be

is simply that it's hard.

One does not simply pair programming.

You don't just sit two people together

in front of a computer, and it just clicks, and it just works.

So what I want to do is I want to talk a little bit about some

of the reasons how pair programming increases

effectiveness, the effectiveness you can't measure.

Then also talk a bit about what's hard about it,

and some ways to tackle that.

And then finally, after talking about those challenges,

a little bit about, is it really worth the hassle?

So I'll start with effectiveness.

And the first category there is really about

that one plus one in pair programming

is greater than two.

So the probably most commonly mentioned and well-understood

benefit of programming is knowledge sharing,

or complementing your knowledge to come to a better outcome.

Just the practice of pair programming

does not guarantee that, though.

People need to move around, break up knowledge silos.

Maybe not everybody needs to see everything.

But still, pair programming makes it easier

to share the ownership of the code across the team,

and it also makes it less scary to move around.

The second thing is that it enables you to combine

two modes of thinking.

So the typer can actually be in a more technical mindset,

really focus on the lines of code

at hand, maybe the local optimization

of what's going on, whereas the person sitting next

to the typer can take a step back

and look at the big picture, maybe already think

about the next problem you're going to run into,

write that down, and really take advantage of that.

It's actually a common thing sometimes

that that other person also is in technical mode,

and then you might not get as much out of pair programming

as you could.

And thirdly, it really helps you reflect, not just on the code,

but also on the story, what value it brings

or what value it might not bring.

And this really goes into what I mentioned before

about effectiveness versus number of lines of code,

because that reflection with each other

might actually maximize the number of lines of code

that you're not writing and that you will not

have to maintain in the future.

So secondly, it really helps you focus.

For example, pairing has also when

I'm working solo, given me a lot more discipline

around the structure, how I approach, how I plan my tasks.

And when I pair with someone, I'm

also forced to explain and justify

why I want to take a certain direction

and discuss it with the other person.

So it helps me avoid the famous rabbit holes.

Or as one of our colleagues said it recently on Twitter,

"I get more programming productivity

out of reducing the time that I'm

stuck than from increasing my speed when I'm not stuck."

So it helps with focus for the pairers,

but also focus for the team.

So introducing a work in progress limit for a team

can have a huge impact on the team's flow and ability

to deliver a good quality.

So let's say you introduce a work in progress limit of three

or four stories, and you have like a two-pizza team,

then pairing is almost a natural consequence.

And it helps you really reduce the number

of balls your team needs to have in the air at the same time.

And lastly, pairing helps you practice

true continuous integration.

So what do I mean by true continuous integration?

So you get code review on the go, you get

more collective code ownership.

And both of those things help you

practice trunk-based development,

so really frequent integration.

So the code review after the fact

has a few disadvantages over code review on the go, I think.

So one of them is that sometimes as a reviewer,

you're kind of in the [INAUDIBLE] cost fallacy mode.

So you think, yeah, this is maybe not the greatest,

but it already works, so it's maybe too much hassle

to build it again.

So this immediacy of the code review on the go

really helps catch more things.

And also, a code review process can quickly

become a bottleneck to that frequent integration

that you have.

And the collective code ownership I mentioned before,

so the moving around, can actually

increase the developers' trust for each other,

so you feel better pushing things into trunk more often.

And the State of DevOps Report on the Accelerate book

were also mentioned before.

So the State of DevOps Report actually

found a correlation between high-performing teams

and short integration cycles.

So at this point, I've given a few of the benefits,

and maybe convinced some of you that pairing can

lead to more effective teams.

But unfortunately, it doesn't always.

So it can also be more harmful than helpful,

because as I mentioned before, it's not that easy.

So one thing that people often say about it

is that it's exhausting, so it's energy draining.

And something that maybe sounds like obvious advice

but that we see often with teams that really

want to embrace pair programming, they actually

pair eight hours a day.

And don't do that.

It's just too much.

And also when you work solo, you don't code all day, right?

You have other things to do.

And there's more things to do to complete

a story than just code.

So really take that into account.

Plan your day together and try to find a good balance there.

Also, taking breaks also seems obvious,

but is often forgotten.

Or maybe you don't want to bring it up

if your pairing partner seems more energized,

and you don't want to admit that you need a break.

And one way that can help here is time management techniques

like Pomodoro, where you have slots

of 25 minute times with an alarm clock and breaks in between.

Yeah, just think about switching roles and modes,

how you do this.

So it doesn't have to be 100% pair coding.

You don't have to be joined at the hip all day.

It's actually about pair development as well.

And then some of those energy problems

can actually be solved, and it's not that hard.

But I think at the core of why it's

challenging is really that it's a really

intense mode of collaboration.

So it's really important that you give each other feedback.

And pairing is also a great way to practice this,

because you can do it in small chunks every day

after you've paired with somebody,

and you have a very clear goal of the feedback, which is

to improve your collaboration.

Also, when you first pair with someone,

take some time to talk about how each of you like to work.

So on my team, we've recently played around

with the idea of writing READMEs for ourselves

and then sharing them with each other.

So try out a few things that maybe you haven't tried before.

Tell each other your pet peeves, like I

don't like it when somebody's eating next to me,

stuff like that.

So the awareness of these differences

and how that relates to pairing is really important.

For example, if you are pairing up a really experienced person

with an absolute novice, that can sometimes just not

go very well, and that's OK.

Maybe you don't pair those people up

if it's not working out.

And finally, pairing is hard because it's very personal.

So you're sharing a close physical space.

You're sharing your computers, maybe your messy desktop.

You're exposing which IDE shortcuts you don't know.

And how big of a deal this actually is dawned on me

first when I read a blog post by Tom Howlett titled

The Shame of Pair Programming.

And in there, he says, "To pair requires vulnerability.

It means sharing all that you know

and all that you don't know, and this is hard for us."

And he goes on to say, "Programmers

are supposed to be smart.

Most people look at what we do and say, I could never do that.

And it makes us feel a bit special,

gives us a sense of pride, and pride creates invulnerability."

And I think this also goes back to what Jean Bartik found

so great about pairing.

She said, "You can criticize each other

and find each other's errors."

But if you're not open to that, exposing what you don't know,

then that actually creates more problems than it's beneficial.

So this works best in a very positive and safe team

environment where everybody really

believes in the prime directive that everybody

is doing the best job that they can

with the information at hand, and in the context.

So after I talk about these tough challenges

to get those benefits, I want to finish on talking about,

is it really worth the hassle then?

So you will be more successful at pair programming

if you work on all the skills helpful to overcome

those challenges.

Concentration, for example, is actually

something you can practice.

Task organization, time management, communication,

giving and receiving feedback, empathy, vulnerability.

And the list might seem daunting for just this one

extra practice you do.

But actually, those are all things that you need on a team

anyway.

So if you want a good gelled team, you need those anyway.

And pair programming gives you a chance to work on them,

even if that might feel uncomfortable at first.

So I went to the Lead Developer Conference

in London a few weeks ago, and I saw Pia Nilsson from Spotify

speak there.

And she talked about how when they introduced all these

practices to improve flow, so a work in progress limit,

test-driven development, pair programming, mob programming--

so that was great in theory, but it actually

reduced the fun on the team and increased the friction--

so anxiety, and conflict, and stuff like that.

And I think another factor you could add here

to this graph of increasing friction is diversity.

So it's also something that's generally

talked about as something that improves team performance.

But often, at first, it increases

friction between people.

And diversity on a team can also actually increase

the challenges with pair programming,

I talked about before.

And things like being vulnerable are often harder or even more

risky for people on the team from under-represented groups,

because you're more exposed.

So I read this article on Harvard Business Review.

Diverse Teams Feel Less Comfortable-- and That's

Why They Perform Better.

And they're saying in there that homogeneous teams

feel easier, but easy is bad for performance.

And that seems a bit weird, right?

So the authors are also saying, this idea

goes against many people's intuition.

And often, if there's something counter-intuitive,

there's a cognitive bias hidden away somewhere, right?

And the one that they're mentioning here

is the fluency heuristic, which says that we prefer information

that is more easily processed.

And if it's easily processed, we think

that it's more true, more right, more beautiful.

And that serves us very well in a lot of situations

in software development.

I think we want readable code, easily processable things.

But I don't think it serves us well

if we think that's why we're not doing pair programming.

So pairing feels hard, but that doesn't mean it's

not good for performance.

And also, it doesn't have to stay hard.

And I've talked so much about how it's really hard.

I just want to mention once that this is actually

a benefit that a lot of my colleagues

mention almost immediately in their top three about pairing,

that it's actually fun.

So for those of you who have had bad experiences,

it can actually be fun.

Promise.

And if you aren't there yet, then there

are ways to make it easier.

So Pia went on to talk about what

they did to reduce that friction, that conflict,

the anxiety, as she talked about feedback,

nonviolent communication, psychological safety, humility,

positive retros, a sense of purpose for the team.

So I really recommend if you're interested in this

that you watch her talk.

And maybe what Kat just talked about also

fits in here as possible solutions.

So pair programming, extreme programming,

agile as a whole is all about embracing change,

because we realize that change is inevitable,

so we want to prepare for it.

And I think another thing we should embrace and prepare

for is this friction that I just talked about,

because it's also inevitable on the way to becoming

a high-performing team.

And I don't mean by that, let's just

have conflicts all the time and feel uncomfortable.

But let's prepare the tools to deal with this as a default,

not just when a team is doing badly.

So practice feedback, practice better communication,

all those things.

And I'm ending a talk on pairing with this

because I believe pair programming is often avoided

because of those potential conflicts

and because it's so personal.

But if you consciously see it as a skill that you can develop

and that it actually helps you get better at other things

as well, then you prepare yourself and the team

for the inevitable friction that you

will get on a diverse and high-performing team,

and you will collaborate better as a whole.

And maybe almost like an unconscious

continuing the heritage, I have a lot

of amazing women developers around me right now

who are pushing the conversations about pair

programming and trying to make everybody better at it,

so I want to end on that.

[APPLAUSE]