Pair Programming - Elephant In The Room

Sowmya Guru at UXDX Community: Berlin. Video: https://www.youtube.com/watch?v=YWiKXYtENvI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why I call this talk the elephant in the room

[00:00:00] My name is Sowmya, and I'm working as a freelance Android engineer in Berlin, and I'm also the founder of Coder Bee, an inclusive network that focuses on women and minorities in IT to learn to code. And today I'm here to talk to you about pair programming, one of my favorite topics. I call this talk Elephant in the Room mostly because, in my experience, I realized that not many companies have embraced this concept, and also not many developers are willing to try this.

[00:00:37] I did quite some research and realized there is a need to promote this, as I have seen a lot of benefits from pair programming in the past. And I want to say that pair programming improves the quality of the product. It helps in inculcating better team culture, and also boosts team morale. If done right, of course. So today, I hope I'm going to give you some pointers that you could use to even advocate this concept if you're already a pair programmer. Or, if you've never tried pair programming, maybe I can convince you to try this.

From the archives: the first pair programmers

[00:01:30] From the archives, in the 1940s the first programmers were a group of six women who worked on the ENIAC machine. And among the six programmers, Jean Bartik and Betty Snyder were pair programmers. I'm quite surprised that even when programming was a very new concept, these two programmers realized that pairing would be very beneficial during programming.

[00:02:07] In one of Jean Bartik's interviews, she says 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 and find each other's errors and use the best ideas." And this is also one of the reasons I think most developers don't want to try pair programming, because you have to be vulnerable, and you're exposed when you have to try programming with another person. You have to be able to allow this person in, and let them criticize you, and let them find errors in your code. Which is not easy when it comes to programming, because we have some sense of pride about our work.

[00:03:07] The first time ever the mention of pair programming was in a book called Extreme Programming Explained, by Kent Beck, and that was way later, that was 50 years later. This concept advocated pair programming as the core concept for software engineering when it comes to collective code ownership. So to promote collective code ownership in a team, it is important for everybody on the team to have a certain level of knowledge about the code, and because of pair programming and rotation of pairs, this could be improved and most of them on the team could have the same level of understanding.

What pair programming is, and the qualities it needs

[00:03:57] So what is pair programming? Pair programming is literally when two developers are sitting in the same location, or on the same workstation, and producing a piece of code. But these days, of course, we have different tools with remote programming to pair program, and it is not any more required for two programmers to sit together physically. Pair programming is more of a social activity, which is why it requires soft skills, and these soft skills can be learned and honed by using particular techniques, just like any other skill.

[00:04:44] I want to throw some light on the qualities that are required to be a good pair programmer. Of course, when you're not pairing, you don't really need to communicate that much. You don't need certain qualities which are usually important when you're working with a partner. So let's talk about what are some qualities that are important while pairing.

[00:05:11] First and foremost, I think communication is definitely one of the top qualities you need to know to be an effective pair. And with good communication, you would also have to have openness of mind, just so you can accept others' opinions and ideas willfully. And also empathy is one of the top qualities, so you understand where the developer is coming from. It helps also to know the background of the developer, to understand why they're saying what they're saying, or to ask for logical arguments, because to know that another dev is also trying to do their best is key to this.

[00:05:59] And other qualities like honesty and patience are definitely highly appreciated, because if you hurry somebody, it's definitely not so good. Especially when you're programming, you don't want somebody to breathe on your neck when you're programming, and it is definitely not useful even if you did. Qualities like honesty and vulnerability will always help you show what you know to your partner, and to have this mindset of not being judged and being vulnerable always helps make good connections, to let people in and also let them know what you know and don't know. So they can help you with what you don't know, maybe.

[00:06:50] Having courtesy and good manners go a long way, mostly because you're working with someone for longer sometimes, and maybe you're seeing them every day, meeting them to work on something. It's very important to be very courteous. And of course, placing trust in somebody is crucial, especially in every team. As a team member, it's important to go in with the attitude that you already trust the person. In total, what I'm trying to say is, when you're trying to pair program, you definitely have to be super nice, super patient and empathetic, and try to listen and have these qualities of having an open mindset to grow together.

The myths that keep people away

[00:07:45] There are still common ways that we pair program. Of course, solo is most people's choice, I think, as far as what I've seen, and pair programming is also quite popular amongst some companies. And these days, of course, remote programming has taken over mob and pair programming, obviously because of corona. So mob programming is when a group of developers get together to actually solve a problem.

[00:08:23] And the question is, why should we pair program? There are certain myths I want to first cover, as to why people would actually disagree with pair programming or they're unwilling to try this. And the top concern for companies is, it increases development costs. My argument here is, of course it might look like it is increasing development costs, but if you are a consultancy, or if you want to maintain a sustainable continuous integration of code base, it definitely is a good investment and it is a long-term investment.

[00:09:10] You will not see the benefit of pair programming immediately, which is why people think if there is no immediate effect then it's not helping. But maybe if you give it a shot and see that over a period of time, it's basically a medium to long-term investment. So the longer you practice this, the better the code quality gets, and less of rework, which means the productivity and effectiveness increases.

[00:09:45] Parallelizing work speeds up delivery: this is another myth, that people think parallelizing, like making one developer do one thing, would actually speed up developing. But it takes a lot of integration time and reviews time, et cetera. So it might not also be true that parallelizing would actually deliver good products.

[00:10:13] And some people say pairing should be optional based on personality types, and others say developers get lost in the rabbit hole. It could be true if you don't know how to pair program correctly. But the most common one I see is also, it halves developer productivity. And in one of the talks, I saw that Martin Fowler, who wrote this blog about pair programming misconceptions, says, "That will be true if the hardest part of programming was typing." And of course, programming is not just about typing. It requires thinking, designing, ideating, and it's a lot more.

[00:10:58] There are two major problems which I think are why pair programming is not popular. And that is, firstly, you cannot measure the productivity and effectiveness that are involved. You cannot tell how many people worked on what, and how much time they spent on this project, and things like that. So it's really hard to do this, and how this improves with time, how pair programming improves the code quality or improves the knowledge among the team. This is also something that's hard to measure. And it is not easily implementable as one would imagine, because if you see developers who are unwilling to actually try this, then it's definitely not going to work. Which is why it's important for developers to know why this is a good concept to try.

Why pair programming: the benefits

[00:12:11] So, why pair programming? It has been shown that 15% fewer defects were found in code that were produced by pairs, and overall code quality increased by 18%, and it reduced also the long-term costs by 18%. Which means that this is not a short-term game. It is more of a long-term investment.

[00:12:41] This concept also produces fewer defects, mostly because you're on the way doing code reviews and you don't push code without any reviews. So that means also the code undergoes reviews two times, during the code development and also after it's done, so there are two safety nets. Pair programming also improves focused work, and also it increases the skillset and knowledge sharing in the team. This leads to better understanding of the code, and also avoids knowledge silos in the team. And knowledge silos is a key person risk, which means you depend on one person for consultancy over a topic, or let's call it a subject matter expert. And this is not good for a team, because we want everybody on the team to be on the same level of knowledge, domain knowledge, and also understanding of the code, et cetera.

[00:13:55] Another good reason to try pair programming is it helps in quick onboarding. It is also one of the reasons the quicker you develop and you're able to continuously integrate, it leads to faster delivery. So that means continuous integration is quick. It leads to collective ownership of the code, which increases team morale and also boosts good team culture. And most of all, it also reduces rework and accumulation of technical debt, which is one of the biggest traps in software engineering, as we all know.

[00:14:40] And last but not least, mostly because it is fun to work with a pair. I think if you believe that you want to improve code quality and have constant review processes, to let somebody know that you're making some mistake, then obviously this concept is for you. And once you get to know people, and once you get to know what techniques to use and how to use them, I can assure you this could be really fun.

How to pair: setup, roles and techniques

[00:15:22] So let's get to the point as to how to pair program. First, focus on the setup and review your setup. When you're obviously not pair programming remotely, then you would need one computer, two monitors, two mice, two keyboards. But when you're remote pair programming, then you need two computers, two mice, keyboards, and monitors, and you also need some tools and apps like video conferencing, a messenger app, jamboards for brainstorming, remote desktop sharing, controlling tools, et cetera. Make sure you review the setup and you have an ergonomic setup as well, mostly because if you do long hours of pairing then it could get quite taxing.

[00:16:21] So let's talk about navigator and driver roles. These are the two roles that you could be in during pair programming. What does the navigator do? Navigator is in the tactical mode, or what we call like a high-level bird's eye view of direction mode. And driver is a person on the keyboard writing code, who's in the mechanical mode. So navigator tries to look at things that might be a potential problem, or can pose some errors or defects in the code, and also tries to outline the direction of work. And the driver literally is working on writing the code, which means is in the mechanical mode, trying to get the tools, and syntactically to check compilation errors and things like that.

[00:17:24] So there are a few techniques that both driver and navigator could use to have a smooth pairing session. And one of the methods is, let's start with the time management methods. Pomodoro is one of the time management methods you could use. As I was saying, do not do a long hour session, because you always want to break these bigger sessions into smaller sessions. So for this, you could use the Pomodoro technique, so you don't start pairing for long hours. You need to also write down certain tasks that are leftovers, or that need to be done next, or if you miss some corner cases, somebody can write it down. Mostly the navigator does.

[00:18:25] During pair rotation, you might want to also use a technique like the ping-pong method. So in ping-pong method, you write a test and then the other person writes code, and then the other person writes a test and the next person writes code. So this way you actually don't get overwhelmed sitting on one role for a long time.

[00:19:01] I would advise using a pairing template before you start. So what does a pairing template consist of? It consists of basic ground rules as to when you take breaks, or after how much time you take breaks, so how much time is required, and what tools you'll be using. For beginners, pick up an easy task. Completely easy task, which you know how to code or what the solution is. And then pick a really personable developer, because if you know that you are not very comfortable with pairing, definitely it helps to have a developer you're acquainted with, you know very well. And do not sit for long hours without taking breaks, it could cause exhaustion, so take breaks. And of course use something like Git Duet for proper attribution: this attributes the author of the code with what you have actually done. And always end the day, or your session, with a mini retro, and talk about your achievements and also what could be improved.

The challenges, including diversity

[00:20:22] And definitely, as I said, it's not an easy thing or a natural thing to pair program. There are challenges that come with pair programming. So just breathe. It's okay to be nervous. It's something that we all share and it's not just you, maybe the other person is also nervous. So just try to make each other comfortable by following some good courtesy and trying to be super nice.

[00:20:55] And nobody said it was easy. It's an intense collaboration work and it requires deep focus, which means it's exhausting. So definitely do not do this for long hours, and always try to work it in a way that whatever you do works with your pair. And of course, this is one of the challenges: since it's a soft skill that is important, if it's not done correctly, or if you don't use proper techniques and feedback loops, it could be exhausting. It could lead to friction in the team. It could cause discomfort, physical discomfort, if somebody's personal hygiene is not good. And it might also feel like an imposition when you're not willing to do this and somebody in your team says, "Okay, we always do this anyway." So that is something you have to keep in mind.

[00:21:54] And also, I want to bring up this topic of diversity, because if you're working in teams that are diverse, it is definitely not going to be easy. And that means that it is also better for performance, because according to a study done by Harvard Business Review, they say that, "Diverse teams feel less comfortable, but that's why they perform better." But again, homogeneous teams feel easier to work with each other, but that is bad for performance as well. So definitely let people in. If you never worked with a woman before, or you've never worked with a person of color, there are always prejudices or biases involved. But I would recommend that you have an open mind and make this a habit. First, start slow and take it easy, so it becomes easier for both of you to pair program.

Things to avoid

[00:23:09] Things to avoid. Definitely, drifting apart is one of the annoying things you could do, when somebody is trying to navigate you or is trying to write code and you're drifting apart. It's definitely not a good thing to do. And when you're being navigator, do not enter a micromanagement mode and start dictating code instead of providing high-level instructions. So let me give you an example. High-level instruction would look like, can you please print the statement? And micromanagement looks like, can you start writing system dot print f dot something? You know what I mean. Nobody wants dictations.

[00:23:57] And of course, try not to be impatient. Some people take longer to figure out things, and some people might be super fast and natural at pair programming. But give your pair a chance to know you, and also give your pair a chance to figure out things by themselves. Try not to be impatient or show the impatience.

[00:24:26] And I also see that, on similar lines, people don't want to give away the keyboard. It's like, if you're on the keyboard then only you're writing code, which is not true. Coding requires both strategic and tactical mode of programming, which means keyboard hogging is not about writing code all the time.

[00:24:51] And definitely, avoid pairing for eight hours a day. I would totally not recommend this. I know some people say we are always pairing, but do take your own time. There's much more than writing code. There's project management, there are meetings, and there are things sometimes: project implementation, details, communication, et cetera. So don't do eight hours of pairing. And of course, definitely make sure that you have a proper strategy in place to take breaks.

What a successful pairing session looks like

[00:25:30] And last but not least, there is of course no silver bullet, no right way of pairing. There is nothing that is right or wrong. It's all about figuring things out with your pair, and seeing what makes them feel better, what makes them feel uncomfortable, and adjusting accordingly.

[00:25:52] A successful pairing session looks like this. Agree on a high-level goal, and break down your high-level task into simpler, smaller tasks and prioritize each one of them. Decide on certain techniques of pair rotation and time management, et cetera. Of course, configuring: already you should have your git configured to share credit for both of you, or everyone in the team. Try to eliminate distractions, keep away your phones, put away whatever distracts you, and find a calm place to program. Take enough breaks, and definitely end with the mini retro.

[00:26:35] And this is a very important part when it comes to pair programming, and this part is what I see most developers skip. And I'm also guilty of this at some point of time. But once I got to know that feedback loop is super important, to tell your partner, it gives you a platform to talk about what is bothering you, what is making you uncomfortable. And it also gives you the chance to offer some constructive feedback, so you could implement that in your pairing session, so your next pairing session definitely gets better. And do not forget to also point out what was better, what was good, and what you want to keep, and share this feeling of achievement, and have a donut.

Being an effective pair

[00:27:34] You're an effective developer when you think out loud, you listen carefully and make suggestions, and you don't show impatience or frustration to your partner, and you prioritize learning over productivity, especially when it comes to juniors. It is not always possible to be a hundred percent finish the task, or be productive, when you have to mentor somebody. So it's okay if you have to invest in this, because companies do know that you have to invest in juniors. And respect personal space: definitely keep some distance and have good hygiene, just so that you don't make your pair uncomfortable.

[00:28:20] And at the end of the day, we're all human, and it's super important to be empathetic about this fact, that somebody has a challenge or is facing some problem in their lives. So it is okay to not be a hundred percent there. Sometimes it's okay to be unmotivated, and that is exactly why you need a pair, because on those days you can just fall back and be a rubber duck and just depend on your pair to help you. So definitely pair programming helps you to always not be on your toes when it comes to programming. Developers need some help some days, and we'll be unmotivated, so you need some support as well.

[00:29:07] So it's okay to be vulnerable. It's okay to not finish something, it's okay to take breaks. And I also see people not interrupting when they really want to take a break, but they just go on because their partners are in high spirits and things like that. But it's okay to say, "Okay, I've had this. Today I'm done and I want to just stop pairing." It's okay to even say that.

[00:29:48] And last but not least, I want to credit a few people who I learned a lot from, especially regarding pairing. Shambhala[?] is one of the site reliability engineers who also talks about pairing, and I learned a lot from her. And a lot of resources from ThoughtWorks, a blog by Martin Fowler, helped me also learn about this concept. And then I also started writing some blogs myself.

[00:30:20] So that's pretty much what I want to say today about pair programming. But I also encourage you to take a look, read about pair programming, and also see what works for you and implement that with your pairs. Because like I said, there is no silver bullet. There is no right or wrong way of doing this. Just try it and see if you enjoy this. Thank you everyone. And just one last thing, see you all tonight at 6:00 PM for Q and A, try not to miss it.