Pair Programming - Elephant In The Room

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, and I call this talk Elephant in the room mostly because in my experience, I realized that not many companies that have embraced this concept. And also, not many developers are willing to try this. And 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 boost 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 you could also, if you've never tried programming, maybe I can convince you to try this. So, from the archives in 1940s, the first programmers were a group of six women who worked on the INAC machine. And among the six programmers, Jean Bartek and Betty Snyder were pair programmers and 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. In one of Jean Bartek'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 and which is not easy when it comes to programming, because we have some sense of pride when as in about our work. So, 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 and 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 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. 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 and 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. 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 and 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. And other qualities like honesty patients are definitely highly appreciated because if you hurry somebody's, 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. Quality like honesty and vulnerabilities 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. 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 to 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 being having an open mindset to grow together. There still common ways that we prep 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 is 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. And the question is, why should we pair program? There’re certain myths I want to first cover as to like 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 isn't 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. You will not see the benefit of Pair Programming immediately and 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 medium to long-term investment. So, the longer you practice this, you will see the better the code quality gets and less of free work which means the productivity and effectiveness increases. Paralyzing work speeds up delivery, this is another myth that people think paralyzing 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 paralyzing would actually deliver good products 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 program correctly. But the most common one I see is also it has 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 or it requires thinking, designing, idea thing and it's very a lot more. There are two major problems which I think are why the pair programming is not popular. And that is firstly, you cannot measure the productivity and effectiveness that are involved. And you cannot tell, like how many people worked on what and how much time they spend 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 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. 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. This concept in also produces fewer defects, mostly because you're on the way doing code reviews and you don't push code. 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 awards 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. 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 collect your ownership of the code which increases team morale and also boost good team culture. And most of all, it also already reduces rework and accumulation of technical debt which is one of the biggest traps in software engineering as we all know. And last but not least, mostly, because it is fun to work with a pair and I think if you believe that you want to improve code quality and have like 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. So, let's get to the point as to how to pair program first focus on the setup and review your setup. So, when you're obviously not Pair Programming remotely then you would need two computers, two mice then you would need one computer, two monitors, two miles, 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, messenger app, jam bodes 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. So, let's talk about navigator and driver rules. So, 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 post 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. 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 Pomodoro technique. So, you don't start pairing for long hours. You need to also write down certain tasks that are left overs or that needs to be done next or if you miss some corner cases, somebody can write it down. Mostly, the navigated does. During pair rotation, you might want to also use a technique like 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. I would advise using a pairing template before you start. So, what does a bank template consists 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 you know what tools you'll be using. For beginners, pick up 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 to like Git Duet for proper attribution and these attributes the author of the code with what you have actually done and always end the day or your session with the mini retro and talk about your achievements and also what could be improved. And definitely, as I said, it's not an easy thing or a natural thing to pair program. There are challenges that comes 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 and nobody's 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 that since it's a soft skill that is important and 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 is personal hygiene is not good and it might also feel like 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. 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 and if you never worked with a woman before or you've never worked with a person of color, or 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. 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 goal 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, right? Nobody wants dictations 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 you a pair of chance to figure out things by themselves or you could also have them. Try not to be impatient or show the impatience. And I also see that on the 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. It's coding requires what strategic and tactical mode of programming which means keyboard hogging is not about writing code all the time. 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're 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. And last but not least there is of course, no silver bullet that is right away of pairing that is nothing that is right or wrong. It's all about figuring things out with your pair and see what makes them feel better, what makes them feel uncomfortable and adjust accordingly. A successful pairing session looks like this. I 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 get configured to share credit for both of you or everyone in the team. Try to eliminate distractions, keep away your phones, put away whatever the distracts you and find a calm place to program. Take enough breaks and definitely end with the mini retro. And this is a very important part when it comes to 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 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. 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. 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 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, it's also the developers need some help some days and we'll be unmotivated. So, you need some support as well. 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. And last but not least, I want to credit a few people who I learned a lot from especially regarding pairing and Shambhala is one of the Site Reliability Engineers who also talks about pairing and I learnt 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. 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 programming, 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.