 See, I'm a software developer at ThoughtWorks and the talk I'm going to give today is called Daring to Pair. So it is a talk that's going to be about if you haven't already guessed, pair programming. And basically I've been pairing ever since I started at ThoughtWorks and I've been having a lot of thoughts about it and I really wanted to just distill and articulate some of the insights I've gained around this. So this session is going to be half talk about some of the technical whys and how's of pair programming and also the biggest lessons I've learned from this whole journey of Daring to Pair and half demo where I, together with my colleague Amanda, are going to show you guys some good and bad pairing in action. Alright, so first the talk. I've been pair programming for five months now and it was difficult at first, right? It's been pairing, frustrating, challenging. But as I've gotten better at it and more used to it, I do like it and I appreciate its effectiveness more and more. And I do believe that in many ways, it has made me a better developer and in many ways it has made the teams I've worked with become better teams. So let's go back to the start of my pairing journey. I'm at ThoughtWorks training program for grads, which we call ThoughtWorks University. Every day we have to pair with each other on coding dojos and projects and I'm nervous. I'm excited to learn but I'm uncertain, right? This is a new thing for me. I'm used to working solo, working independently and thinking my own head, not really talking to people much. I'm in this situation where I have to work really closely with this other person that I don't know all that well and I have to learn to vocalise my thought processes and get used to having someone staring at my code as I type and be considerate to my partner and match their pace, be patient and explaining things. And I'm not used to it and it's tiring. I find myself getting impatient so many times. And sometimes I get the sense, you know, man, if I've been working on this task solo, I get it done so much more quickly. Other times I can't think properly with someone constantly watching me as I code. I get self-conscious and anxious. And sometimes I just get annoyed when my partner disagrees with me, right? But as the weeks go by, I'm starting to realise some things and I start to get better. I go from being really unused to talking through my thoughts while coding to being able to do it quite naturally. I go from being anxious about being judged by my partner to being able to view them as what they really are, right? A partner who is here to collaborate with me to solve problems, to bounce ideas off, to think things through with and to share knowledge to catch each other when either of us slips up. So I go from being easily frustrated and impatient with a partner who is slower and less familiar with the code we are working on to bring them as a teammate that I have the responsibility of enabling and bringing along and I hone the patience in me to do so. So by the end of ThoughtWorks University, by the time I start on an actual project as a developer consultant on the client side, I'm realising more and more the ways that pairing has helped me grow as a developer. And I don't have that much time but I want to share some of the most important ones in my opinion with you today. Now, honestly, that's probably in tons of articles and blog posts and talks about pair programming and its benefits and how it weighs up in solo programming. In fact, some ThoughtWorkers from Germany put together this super awesome pair programming deck, which is really one of the best pair programming one of ones I've ever seen. But I will not have time to do justice to all of it. I'm going to gloss over some really important points, right? Like how pairing really helps produce better quality code and saves time compared to traditional code review. And how it really helps to keep you focused on the task and allows you to work through tough problems better. But what I really want to bring across is one of the biggest realizations I've had about why pairing is so important. And so much of it I realised really just about teamwork and communication. Now before I zoom out to the macro level of the team, I want to go back to the skills that I mentioned that pairing helped me as an individual improve upon. So communication, right? Becoming a good explainer, something super important as a consultant. Or even, you know, if you're in the lead role, you're going to have to find yourself in a situation where you have to explain technical decisions to non-technical people sooner or later. And if you're not even able to do this with other technical people, that is your partner, that's going to be a problem. And pairing really helps to train the skill. Realising the importance of bringing my teammates along. Now this is super and super important. And pairing was something that helped me realise how important this was. When I wrestled with the impatience of working with a partner who was struggling more with the code than I was, I realised I was faced with two choices, right? I could be the jerk with the big ego and ride on resentment and blame my partner for slowing me down. Or I could gently guide my partner along, patiently explain to them the things that needed explaining and watch them level up and grow their contribution towards the team in the long run. You can guess which one I chose. Getting to know my teammates better. This is so important for team camaraderie and just having a pleasant work environment in general. But you know those awkward moments where you're waiting for the test to run or where your project is just rebuilding? It's a perfect time to find out more about your colleague or just, you know, talk about something silly and random. So in the project I'm on right now, I was pairing with this colleague one day and he randomly starts talking about his serendipitous discovery of this half-naked gym in his neighbourhood and we started talking about all sorts of silly random stuff in the interval. And so, you know, you have fun, right? When you're pairing is work but you should also have fun with your partner. So let me ask a question. Would these things matter if you were the only person working on a project or even if there was like only two of you working on a project? Probably not very much, not that much. But you know, let's face it, right? How likely or often is that ever going to happen? Just like one dev on a project. I guess like maybe in smaller companies like startups, it definitely can happen. But a lot of the times you're going to be working in a team. And once you're working in a team, all these skills are super important to have as an individual and pairing really helps to hone these skills. Now zooming out from the individual level to look at the team as a whole, pair programming does so much to help in these three areas, right? Knowledge sharing. I say this from personal experience that this is a huge challenge when working in big teams. I work in a pretty big team right now. And as the team has grown, we've increasingly faced the problems of people losing contacts about different parts of the code base or silos of knowledge developing around just one or two people. And none of this is good but pair programming with disciplined pair rotations, meaning switching up your partners every so often really helps to alleviate this problem. And you know, of course, pair programming is not the only way of knowledge sharing but you can have like stuff like tag cuddles, code reviews and so on. But I will say this as a truism almost. There is no better way to gain knowledge about a part of the code base than actually writing that piece of code yourself. And that is what pairing with frequent pair rotations gives you. So collective code ownership. Going back to the problem of silos of knowledge developing around just one or two people, it's never a good thing, right? You're going to meet a lot of problems with ego where that rock star developer who has worked on one entire part of the code base on his own is going to be very resistant to change from other people in the team. And other teammates are not really going to dare to, you know, try to change anything in that part of the code base because they don't know it well enough. And so eventually, before you know it, that part of the code base starts growing so complex and unknowable to the rest of the team that rock star developer just becomes like a single point of failure for your whole team. And this is the time for a fun anecdote. So I was talking to a business analyst on my team who has had a lot of experience working in traditional enterprise environments. And there was one team which had this tech lead who was the only one who knew anything about this very crucial part of the code base. And one day, the guy just disappeared. He literally vanished, ghosted, right? And he took all the contacts and even the code with him. And they literally had to get a police search warrant to go to the guy's apartment and retrieve his laptop and get the code so the team could continue working. So this is a pretty extreme case, right? But I hope you get the point that with pair programming, you avoid these kinds of knowledge silos and you get the whole team to own the code. You don't shame any one person if some part of the code breaks or is poorly written and likewise you don't worship any one person who's architected and entire part of the code base on his own. Finally, onboarding new team members. Oh man, how grateful I am for this because I had such a seamless onboarding onto my current project when I first joined and it's really thanks to the patience of my teammates who pair with me and the knowledge transfer, the ease of knowledge transfer you get when you're pair programming. And I was up to speed and contributing effectively in no time and pairing help immensely. I was learning new things and gaining context really quickly and it definitely would not have been the same without pairing. So I've been talking a lot about the benefits of pairing but I don't want to make it sound like a penacea for everything, right? Pairing is just a tool. You have to use it in the right situations for it to be effective. So I'm gonna briefly run through some situations where pairing may not be such a good idea. First, tedious road work. Now surely it does not make sense to pair on a fairly brainless task but the caveat stolen from Martin Fowler is if you are doing road work, maybe you're missing a key abstraction somewhere and maybe your pair can actually help you figure it out. A different set of eyes to look at a problem in a different way and to challenge your pre-existing assumptions. Then again, this is not always the case I admit. Arguably a lot of UI work is as long as you're sufficiently competent in it and don't need a partner to enable you. I agree, UI work involves a lot of unavoidable repetition. It's like just fiddling with padding, right? So in that case, I think not pairing is pretty justifiable. Next, when neither of the pair knows very much, well there might be cases when you're both working in a stack and neither of you are very familiar with, in which case it does make sense, I think, to split up and do your own research, your own spiking, your own Googling, trying things out, learning as you go. But I think it's still very beneficial to actually have a partner to come back together as with and once you've done your individual exploration, you come back together and share what you've learned and it's also a way to keep each other accountable, right? You don't lose track of the task you're supposed to do. So you know I put this as under when not to pair. It's more like still have your partner but you don't actually have to actively be pairing, sharing a keyboard all the time. Finally, when one of the pair is too green and fresh, so sometimes it can be hard for a newbie programmer to gain a sense of independence and confidence if they start pairing from the get-go, right? So for newbies, it may actually be beneficial to go solo for a little bit or even to pair with another newbie programmer of about the same level so that you can kind of bang your head together and help each other work things out rather than pairing with a senior who may end up spoon feeding all the answers and undermining the independence that you get from actually banging your head against the problem. So with that, I want to share some of the hard lessons I've learned through my pair programming journey. Some of you may think that this looks like I'm writing some kind of relationship guide, right? But actually, you know, seriously, it is kind of like that because pair programming is a very intense and personal act of collaboration and I think it's much of a surprise that some of the same guidelines apply here. So first of all, be self-aware. Where do you usually trip up? Keep that in mind and work on it. You ask your partner to keep an eye on those things when you pair and also, you know, be vulnerable. You have to open yourself up to your own flaws. You have to open yourself to acknowledging those flaws and accepting criticism from others about those flaws, right? Which brings me to ask for feedback. So you may be a self-aware person, but there will always be things that escape your detection and the only way to find out is to consistently ask for feedback and for things that you're consciously trying to work on, a good way to find out if you're actually improving is to consistently ask for feedback from others. Don't let your ego get in the way. It's okay to look stupid and there's no need to show off. You know, if I compare how I onboarded onto my current project with how I got started on my project at my internship company, which some of you may know, there's quite a bit of difference. So when I got onto this project, because of the dynamics of pairing, because of how patient and kind my teammates were, I felt so comfortable looking stupid, asking all kinds of questions, improve my understanding of the project, and I was able to level up really fast. Thinking back to how I was as an intern, yeah, I was really fearful of asking questions and I did a lot of work very independently. I had a mentor who was also very patient and kind, right? But I was both afraid of looking stupid and also afraid of distracting him from his real work, that I hardly asked him any questions and did a lot of the work on my own. And he was very happy with me, right? You did so much work. But when I think back to how I was, I really think that if I had been more willing to ask questions, I could have learned a lot more. So the dynamic of pair programming, which pair programming introduces into the team, really lowers this barrier of fear and uncertainty that a newcomer always feels. And existing devs are already so used to the idea of pairing and explaining their work to someone else that they don't see it as extra burden when a new person comes about. And they're good at it too because they're constantly forced to do it, right? So if you're a person in the pair who's less familiar with a bit of a piece of code you're working on, don't be afraid to ask questions. Your pair should be more than happy to help. And conversely, if you are the person in the pair who's at the advantage, so to speak, there's no need to show off. You know, be patient. Don't put your partner down. When I was at Tolks University, I typed pretty fast and because I use Vim and I use it fairly fluently, I move around quite quickly, right? And a lot of times too quickly for some of my teammates to follow. And as childish as it sounds, I always felt this temptation to just move really, really fast even though I knew my partner couldn't keep up. And of course, sometimes I just ended up doing unconsciously because I'm used to my own pace but they almost always I'd be able to resist this because like really what's the point, right? How good a software product you're able to deliver doesn't depend on some amazing Vim or Emacs skills or whatever. It really depends on how well your team works together and unless you're going to actually spend time levelling up your team members to pick up those same amazing Vim and Emacs skills, you know? You just don't do that kind of thing. Kind of things really just inconsiderate to your partner. Don't let your ego get in your way. Next point, be humble. Yeah, this goes back to being self-aware and vulnerable. They're tied to each other, right? There's always something to learn and your partner will always have something to teach you whether it's through them directly teaching you or you learning something through having to teach them. As I've grown in my humility, I've grown in my confidence too. They go together. Be flexible. So whenever you're working with someone other than yourself, you have to learn to make compromises. I'm sure you all know this. In ThoughtWorks University, we were working in Java of the IntelliJ IDE. Different people had different key macs. I figured I had to learn both. And on my current project, when I joined most of the existing devs were using Visual Studio Code. Yeah, okay, big deal. I just had to learn a new tool, right? And when you're pairing on someone else's machine, you make an effort to learn the way they work and the IDE shortcuts or whatever. And so like I said, I use Vim and that's why I feel most effective using. Until now, I haven't had with anyone who uses Vim, but you know, it's not a big deal, right? When I'm pairing on my machine, I just switch in our Vim mode. When I'm pairing on someone else's machine, I just forego it. I mean, everyone likes to work in with what they're the most comfortable with. But if you can learn to be flexible and not grumble about why your partner doesn't use XXX tooling that you love or work in XXX way that you think is best, you'll be a better dev and person for it. Finally, you're responsible for making the session effective for yourself. To put it another way, you're responsible for being engaged, for working your partner in a mature manner, for not playing ego games and for working on the things that you need to prove and prove upon. For example, and I come back to this again because it's been a consistent problem for me, but for example, I get impatient very easily when I feel my partner isn't getting things fast enough. I could sit and still in silent resentment for the whole session being dragged down by my partner and have a crappy pairing experience at the end of it, or I could make the switch, the mental switch to go into enablement mode and remind myself, since I'm the one who has a better handle on this piece of code, I should be the best partner and enable them, bring them along with me. And more often than not, I'll actually realize something that I didn't realize before about the problem at hand, even if I'm the one doing the explaining. And that choice and the resulting experience from that choice is your responsibility. So on the other hand, obviously I've been in a lot of situations where I'm the more inexperienced side of the pair. And if my partner is moving too fast and not explaining things enough, it's up to me to solve this out and get my partner to slow down and re-explain the parts that trip me up. Because if you struggle in silence, your partner may just like, so do a head thinking that everything is fine and then you just end up sitting and stewing in silent resentment and fear. And again, that choice to speak up and the resulting experience from that choice is your responsibility. Okay, with that, I think I've spent enough time talking about the benefits of pairing and my own personal challenges. So at this point, if you have not done pairing before, you are probably wondering, how do you do it? Show me how do you do it? Okay, so it is no time. I would like to welcome my colleague Amanda to help me out with this. You use VS Code, right? VS Code. This thing is... I have checked that we used it before. It's okay, it's not really matter. Do close this. Sorry, should I prepare this? You know, from VS Code, can you? Yes, yes. You're always intelligent, is it? No, I'm just, I don't remember. Oh, you don't use a lead. Oh. What we're going to walk you guys through is to program a calculator that can calculate a mean and a sum. Hey! So we're going to do this in two parts. The first part will be anti-patterns of pairing anti-patterns. Oh, we do anti-patterns first. Can you guys see? I'm just going to close it. It has been on and off. So, Amanda, we are going to be pairing on this task. Yeah, so... I'm going to implement this calculator that implements sum. It's going to take a list of numbers and find the sum of it, right? Let's do TDD, okay? Task first. Okay, so... Hey, this damn cute cat jiff. That's nice, right? Okay, so this method should take in a list of numbers, right? Yeah, sounds good, sounds good. Hey, let me check this out. Yeah, looks good, looks good. Okay, so I think my first task should be something like... Maybe if I pass in... What happens if I pass in an empty array? What's the sum of an empty array? I don't know. Hey, this is quite interesting. That's it for the first anti-pattern. So, you know, it's really annoying if you're pairing and your partner is constantly looking at your phone and talking about cat jiffs and half-naked gyms and... So... Yeah, so be considerate to your partner. Like, maybe sometimes you have an urgent message and take the call, just let them know. But, you know, it's not just about pairing, right? Even when you're having lunch and dinner with people, it's quite annoying if someone takes out their phone and looks at it. So, second anti-pattern. Okay, are you ready to pair on this one? Okay, so I'm thinking, like, if when you return zero, when you get an empty array, or should it be, like, you know... No, of course not. It should just return zero if it's empty. What are you talking about? Yeah, like, let me do it. Return, I think throw an error better. Yeah, I really don't know it, seriously. Why do you think we should throw an error? I mean, like... I mean, of course, I mean, you don't usually... Okay, so that's the second anti-pattern. Basically, don't be a jerk. Don't snatch your partner's keyboard halfway and, you know, don't dismiss, put them down all the time. Okay, are you ready to pair now? Yeah, let me try again. Okay, I'm gonna say that it should return zero. Okay, because if you have an empty array, well, the sum is zero, right? So I'm gonna expect calculator dot sum, empty array. Okay. Yeah, that's good. Are you doing the third? Oh, okay. Yeah, let's try implementing that. Implement this? Yeah, okay. So first you need a method, right? You define the sum. So I need a static method sum. Yep, and then you need to take in, like, list of numbers, right? So then, the easiest way to make it pass is to return zero. Maybe steps. So we are doing driver navigator now. Yep, so this is a style of pairing where one person primarily types and the other person kind of has a more strategic mindset and guides the driver along and, like, tries to think of edge cases or, you know, abstractions. So I'm gonna run this test. Oh, sorry. Oh, sorry, I'm using yarn for this. I don't know why I'm using yarn. Do I type? It's NPM test, eh. Look at your package, Jason. Oh, this is... Any NPM I? No, okay, of course I was using yarn. Hold on. Oh, is it? Sorry. I cannot trust this. It's okay pair. Encourage your pair, man. Encourage? What's encouragement? It's okay. We'll figure this out together. I've written NPM test and it's fine, eh. Oh, you've written... Yeah, it's just NPM I and then NPM test. Okay, because I was using yarn before, then... Oh, it's my spoon. It's my yarn record. Okay, never mind. Yeah. No problem. Okay, but maybe we can move on. Okay, let's continue writing this first. Yeah, but that definitely passed, like... Yeah. Trust. Trust me. Okay, so let's write the next test. Okay, um, I think maybe we can make it a bit more complex. So we can pass in a list of numbers. Maybe we can define just one, two, three, four, five and see. Okay. So one, two... So one, two, three and your sum of six. Okay? Can come, yeah. Should return six if... It should return the sum. Yeah. So... Maybe I'll just pull it out so that we can modify, easily. This is... Anyway, another good way... Key thing about pairing successfully is to have a proper setup. This is obviously not the proper setup. You're going to get neck pain doing this, but for the sake of demonstration purposes. So ideally you would have a pairing monitor and a keyboard for your pair. Yeah, and two sets of monitors, preferably. Okay, let me run... Let's see if that passed. Yeah, let me see if my tests are running now. What's the right year? Should be tests. Okay, sure. Wow, it shouldn't fail. So one test passed and another test failed as expected, I guess. Yeah, let's try implementing that. So you have a array of numbers. Use sum them. You can try using reduce. Reduce, right? So we're going to take a function that takes a... Yeah, so the first one should be an estimator and then the next one under element. And then you plus sum them. And then my initial value should be... Well, it doesn't really matter, right? Yeah. But what if I'll num? Okay, let's try this. Yeah, we're not checking for empty though. Let's try this. But the first one... Yeah, because you didn't check for empty. Oh no, I didn't, sorry. No, this is the... So this... If you can do an A. Wait, no, this one is a different error. So my second test failed because I didn't return anything. Yeah, man. Damn it. Sorry, this is not a copy script. Anti-penetrate, no calculus. Yeah, so the first test failed because we are passing an empty array, right? So if you want it to be zero, you have to pass in the initial value. Awesome, so red, green. Let's refactor maybe. Yay. You want to do the refactoring? Then I took ping pong. Okay, for sake of time, let's move on to demoing the other style of pairing which is ping pong. So this is a style where you write... It's for TDD, so you write a test and then you watch them fail, randomize them to fail, and then... How much time do you have? Okay, sure. Okay, well, I'll do that. We can't show you ping pong, but there is a ping pong table. You can live with that. Okay, thank you, folks. Hope you learned something about pairing today.