 So, sup people, my name is Jinsi, I am from ThoughtWorks, a software developer from ThoughtWorks. And to be honest, it's kind of strange for me to be giving a talk at Ruby SG again because I honestly have not been touching Ruby in a while, but this talk is really also not about Ruby, so anyway, the talk I'm going to give today is called Daring to Pair. And basically if you haven't realized, it's a talk about pair programming, and I have basically been pair programming for about five months now, working at ThoughtWorks. We kind of do it as a daily practice. And throughout this journey of learning how to pair, I've had some thoughts about it and reflections about it that I really wanted to kind of put together and share with other people. So this talk is going to be about that. So my pairing journey so far, at the beginning it was kind of like frustrating, it was challenging, I wasn't used to it because I went from like being really unused to articulating my thoughts with someone staring at it, like someone sitting right next to me and coding, like live coding right next to them, to actually really appreciating the process and appreciating the growth that it has given me, right? I went from being kind of frustrated sometimes, having to keep along with my partner, having to explain things, to actually realizing and being kind of afraid of asking my partner questions when I wasn't sure of how to proceed, to kind of realizing that pairing actually, like my partner's actually really there to help me grow as a developer, to help me solve problems along the way. And in many ways pairing has really made me a better developer and the teams that I've worked with better teams. So at the start I started pairing when I went to ThoughtWorks University which is a training program for ThoughtWorks grads and every day we have to pair on coding assignments and dojos and projects. And you know, I'm very used to working solo and working independently and thinking my own head so it was really quite a difference. But I start to realize that it's not really about just you as an individual, it's really about you working in the team and pairing really helped me develop those skills that is needed to work as a developer in a team. So honestly, I think there's been tons of articles out there and blog posts and talks about pair programming that really go through some of the benefits and how it weighs up against solo programming. And in fact, we actually have this really awesome pair programming one-on-one deck within ThoughtWorks but I will not have time to do justice to all of that but I'll just really gloss over some of the really important points like how pairing actually helps to produce better quality code and saves time compared to traditional code review or how it helps with keeping you focused on a task at hand and being able to work through complex problems together with your partner. But what I really want to bring across is one of the big realizations I've had about why pairing is so important and so much of it I realized is really about teamwork and communication. So before I zoom out to the macro level of the team, I really want to go back to the skills that I mentioned before that pairing helped me as an individual improve upon. So the first is communication, becoming a good explainer, something that's super important as a consultant or even when you're in a lead role where you're going to have to find yourself in situations where you have to explain a lot of things to technical decisions to non-technical people and sooner or later. And if you're not even able to do that with a technical person, that is your pairing partner, then that's going to be a problem. Secondly, realizing the importance of bringing my teammates along, so this is super, super important, and pairing was one of the things that made me realize how important this was. So when I wrestled with the impatience of working with a partner who was struggling more with the code than I was, I realized I was faced with two choices. You know, I could be a jerk with a big ego and just blame my partner for slowing me down or I could actually switch my mindset and try to gently guide my partner along and watch their contribution grow towards the team. So there's obviously one choice that's more productive than the other. Next, getting to know my teammates better. Actually, this is really important for just team camaraderie and just having a pleasant working environment in general. So you know those awkward moments when you're just sitting there watching your test run, waiting for your build to finish, those are the perfect moments for getting to know your colleague better and you just talk a lot of nonsense. Just for example, I was pairing with this guy in my current project and he just randomly started telling me about this half-naked gym he discovered near his neighborhood and I was like, wow, and then we started watching people flip tyres to work out and that kind of silly stuff. Like, so really pairing is work but it's also for you to really have fun. It should really be a fun process. So let me ask you a question. Would all these things actually matter if you were just working as a single dev on a project or maybe even just two devs on a project? Like, probably really not that much but a lot of times we actually have to work in a team and once you're working on a team, I realize that these skills are really super important for you to have as an individual and pair programming really helps you to hone these skills. So zooming out from the individual level back to the macro level of the team, like pair programming really does a lot to help in these three ways. The first is knowledge sharing. So I can say from personal experience that this is a huge challenge when working in big teams because I work in a pretty big team right now. We have almost like 20 devs working on the same code base and we've grown with increasingly faced problems as the team has grown. Like we're seeing people losing context about different parts of the code base and silos of knowledge developing around like one or two people and none of this is good but pair programming with disciplined pair rotations that means switching up your pairs frequently really helps to elevate this and of course pair programming is not the only way to do knowledge sharing, right? Like you can have tech hurdles, you can have code reviews, but I will say this like as a truism almost there is no better way to gain knowledge about the code base than actually writing that piece of code by yourself and that's what pairing with frequent pair rotations can give you. The second is collective code ownership. So going back to the problem of silos of knowledge developing around one or two people, like I said this is not a good thing. You're gonna meet some a lot of problems with ego where this one guy who's worked a lot on a single part of the code base is gonna be very resistant to change from other people and other people are gonna be very afraid to suggest changes because they just don't understand that part of the code base enough and like before you know it that part of the code base is gonna grow into a lot of complexity and it's gonna become like a single a potential single point of failure for the whole team. So this is actually like time for a really fun anecdote. I had a business alleness, I had a business analyst on my team who used to work in a lot of like traditional very waterfall enterprise kind of environments and he was telling me that there was one team that he worked on with. There was this tech lead who was like the only one who knew anything about this very crucial part of the code base and like one day that guy literally just disappeared. Like he vanished, he ghosted and he took his context with him and they literally had to get a police search warrant to go to the guy's apartment and retrieve his laptop just so they could get the code for the team to continue working. So I mean like this is like a super extreme example and probably most of us are not gonna encounter this but I think it's really good to highlight the fact that having a single person only a single person knowing something about that part of the code base is really not a good idea. So finally, prior programming really helps with onboarding new team members and I'm really really grateful for this because I felt like I was onboarded really smoothly into my project when I first joined and it's really thanks to the patients of my teammates who paired with me at the beginning and the ease of knowledge transfer that happens when you do pair programming and I was up to speed contributing effectively in no time and gaining context about things really fast and pairing helped immensely. I definitely couldn't have done it if we had not been pairing. Now I've talked a lot about how pairing is beneficial but like all things is just a tool, right? You can't just show the same hammer at different objects. So there are cases where I would argue that maybe pairing is not that great an idea. So the first obvious one is when you have to do tedious road work, you know surely it doesn't make sense to be pairing on fairly brainless tasks, right? And I would agree but the caveat stolen from Martin Fowler is that if you're doing road work maybe there is some key abstraction somewhere that you're missing and if you have a partner with you who can sit with you and look at the problem from a different perspective maybe he can help you spot the missing abstraction. But arguably not all kinds of road work are like that. So arguably a lot of UI work as long as you're sufficiently competent in it you don't need a partner to enable you to help you. So it involves a lot of repetition unavoidable repetition like fiddling with padding and such. So in that case I would say that it's really not necessary to pair. Now the next case when it may not be very beneficial to pair is when neither of the pair knows very much so there might be a case where you're working on a stack and neither of you are very familiar with in which case it makes sense to kind of split up and go and do your own spiking, your own research before and you know guling things, trying things out, learning as you go before kind of like coming back together to share your learnings. And so it's like even though you're not actually pairing full time you're kind of still loosely pairing it's in a way to keep each other accountable. So I wouldn't really say that it's a case of don't pair at all but rather you don't have to like actively pair share the same keyboard on the screen. So the final case where I think pairing is not really ideal is when one of the pairs too green and too fresh. So like when you have a really junior dev coming in it can be hard for like the newbie, a newbie dev to gain a sense of independence and confidence when they're constantly pairing the senior who may just be spoon feeding them or just like dominating the keyboard all the time. So in those cases where you've really, junior devs may be beneficial for them to pair together to like bang their head against a problem before they start pairing with more experienced people. Now with that I want to share some of the hard-earned lessons I've learned throughout my pair programming journey. Some of you may think that this title looks a bit like I'm writing some kind of relationship guide but actually you know seriously it is somewhat like that. Pair programming is a very intense and personal act of collaboration and I don't think it's much of a surprise that some of the same principles apply. So the first thing is be self-aware. Like you know where do you usually trip up when you pair, what are you not so good at? So it's a good idea to keep a lookout for that and work and consciously work on it. So ask your partner also to keep an eye out for things that you know that you're not very good at. For example, I tend to speak very softly and way too fast when I pair. So that's one thing I consciously, when I ask for feedback from people I try to ask whether I've been doing well on that. Which brings me to the second point of asking for feedback. So you may be a self-aware person but there will always be things that escape your own notice and the way to find out is to ask for feedback constantly and for the things that you're consciously trying to work on it's a good idea always to like constantly ask for feedback on them to see how you're progressing on them. Third point is don't let your ego get in the way. It's okay to look stupid and there's no need to show off. So if I compare how I onboard onto my current project with how my attitude was as an intern I think there's a lot of difference because when I got into this project I was really quite, I was not, I was definitely nervous but I was not very afraid of looking stupid. Like I was totally okay if asking a lot of questions to figure out more and to improve my understanding and knowledge of the project. Whereas when I was an intern I kind of was like, oh I don't want to bug my supervisor with his real, like I don't want to disturb my supervisor who's doing real work. I should like try to figure out everything on my own. So I ended up doing a lot of independent work on my, so I was like, oh my God, you did so much work, okay, I'm so happy. But I realized that I could have learned much more if I had been more open to asking questions and learning from seniors, which I am learning a lot from right now in my current project. And the reason that pair programming really helps with this is that the dynamic that pair programming introduces really lowers that barrier of fear and uncertainty that a newcomer always experiences because existing devs are already so used to explaining themselves over and over again that they're not, they don't see it as extra burden when someone new comes on board and they have to explain things again. It becomes like kind of like second nature. And so if you're the person in the pair who is like less familiar with a piece of code or less experienced, I think you should not be afraid to ask questions. The devs, if you're working in a good team where pairing is a constant practice, the devs you pair with should be more than happy to help to explain. And you know, conversely, if you're the person on the pair who's at the advantage, so to speak, you know, there's no need to show off. One thing I really look up to in the seniors in my team is firstly, obviously they have good technical chops. Secondly, is that they're good teachers. Finally, be humble. This goes back again to being self aware, you know, they're tied to each other, right? So there's always something to learn whether you are the one learning things directly from your partner or whether you're learning through teaching your partner. So as I've grown in my humility, I've grown in my confidence as a developer as well. They go together. Next is be flexible. So whenever you're working, whenever you're working with someone other than yourself, you have to learn to make compromises. I'm sure we all know that. So when I was in ThoughtWorks University, we were working in Java with IntelJ IDE and different people had like different key maps. So like when you pair with a different person, you're like, oh my God, I have to learn this other key map. And then in the end, I was like, it's great, I'm just going to learn everything. Because it's like you have to be flexible. You can't just say I'm not going to pair with this person just because he uses Control-R and I'm familiar with Command-R or something like that, right? And even when I came to this project I'm on right now, most of the people were using visual studio code. So I was like, okay, I have to install another text editor, why not, right? So you know, big deal, I just had to pick both of them up. And the last time I gave this talk, so I gave this talk at Junior Dev SG before, the last time I gave this talk, I said that I have never paired with someone who uses Vim until now. That has changed in my past pair for the past two weeks. Also uses Vim. So this is the first time I'm actually able to pair with someone who uses Vim. But you know, before that it's like, if I had to pair with someone who doesn't use Vim, I would just be like, yeah, sure, I just forgo Vim. If they're pairing with me, I'll just toggle Vim off. If I'm pairing with them, I'll just like, yeah, whatever, I'll just not use it. So everyone has their own like, you know, comfortable zone, right? The tools that they like to work with. But if you can learn to be flexible and not grumble about why your partner doesn't use XXX tooling or XXX, you know, fancy text editor, right? I think you will be a better person and dev for it. Okay, finally, you are responsible for making the pairing session effective for yourself. So put in another way, you're responsible for being engaged and for working with your pair in a mature manner. Like for example, if like sometimes when in TW, I kind of felt impatient quite easily sometimes because I thought my partner was not getting things quickly enough and I would get frustrated. But I realized that it's not productive to just constantly feel frustrated and like feel like, oh, my partner's slowing me down because what are you gonna gain out of that? So you had to make, you really have to make that mindset switch to say, I'm here to, if I'm the person who has an advantage, I'm here to enable my partner. And conversely, if you're the person who is maybe not like slower or struggling with the code, you should speak up. You should tell your partner that, hey, could you explain this line to me? I don't really get it. If not, your partner wouldn't know. Like, so I have many situations also where I've been pairing this guy for the whole day and then at the end of it, I'm like, so how was it? Then he's like, I didn't like pairing with you. And I'm like, oh, my God, why? He didn't say anything for the whole day. And then you tell me at the end of the day, you don't like pairing with me. So he's like, I told him like, the next time if there's something, sound it out. Because his complaint was he didn't understand a lot of what was going on. I was like, if you didn't understand, please sound it out while you're pairing not at the end of the pairing session. So on whichever side you're on, it's really up to you to make the pairing session effective for yourself. Okay, so I've spent enough time talking about the benefits of pairing and my own personal challenges and reflections about it. So at this point, if you haven't done a pairing before, you're probably wondering like, oh, my God, show me how to do it. So with that, I am going to do a quick demo with my colleague, Denise, who's kindly agreed to help out with me today. And the last time I did this demo, the code was in JavaScript, but I'm obligated to do it in Ruby this time, so. I hope I am right, thank you. I think it's over there already. I've got a mirror to display. What is it? It's going to be a bit heavy. Okay, so the demo is going to start with pairing NT patents for some fun and laughter. So Denise has kindly volunteered to be the asshole pair. All right, so this task that we're going to do is to implement a calculator in Ruby. Hey, look at this cat. It's really cute. I'm still explaining what the task is about. Okay, so Denise, the point of this task is to implement a calculator in Ruby. So I think the first thing we're going to do is write a sum method. So it's going to take an array of items and numbers and try to sum it up and- Wait, I have a phone call with you. Hang on, very important. My sister needs to buy some clothes from this drop shop. Hang on. Okay. Yeah, so like I was saying- I'm sorry, sorry again. I'm going to try to write this method to take the sum of an array of numbers. So let's try to do some TDD over here. Oh, okay. So I'm going to write my first test. Okay. So if the sum of- Okay, so that's the first pairing anti-pattern. The partner who really is not paying attention to you at all or the partner who's constantly checking their phone while you try to pair with them. So really, like, if you're pairing with someone, try not to have your attention drift to something else. It's kind of annoying for your partner. You'll be the dominating one. Sorry? Delete, passive-impressive, delete my quote. Oh, I'm sorry. Okay, so the next anti-pattern demo. So I'm going to write this, I'm going to write this. I'm going to write this test to test what my method should return if, what do you think? If I get an empty array? Yeah, sure, why not? So what do you think, I think the sum of an empty array, I think if the array is empty, we actually shouldn't return, we should like return nil because there are no numbers to sum, thankfully. Yeah, okay, why not? Hey, wait, wait, wait. No, no, I don't think we should do this. I think we should do something else. Instead of returning now, maybe, since we know the process of TDD, maybe we can jump ahead. Instead of returning now, let's just do some normally. Okay? I think we should be checking the, wait, hold on, I know how to do this. No, no, no, wait, wait, wait. This is wrong, okay? Why, why is it wrong? Tell me. Like, dude, you obviously supposed to test your edge cases before you write the... What is your opinion? Look, baby steps, man, TDD. Come on. Okay, fine. Okay, so the second anti-pattern is like being aggressive, passive aggressive or outright aggressive with your partner. So like when you have disagreements with your partner, like don't go and delete their code after they have written it or like dominate the keyboard and snatch the keyboard from them. So I think we're gonna do a proper one this time. So we, there's one terrifying technique that we do called driver navigator which involves mainly the person at the keyboard basically driving, meaning he's the one typing, he or she's the one typing the code. Navigator is kind of the person sitting behind giving comments, thinking about the code at a higher level. So we're gonna try to drive a navigator first. Hey, so I think for the first test case maybe we should start with a simplest empty array, let it return now. So I'm gonna expect... You wanna have it in a before block? Yes, that would be good. One of the tests. Yep. Oh... It says, is it variable? Oh, sorry, yep. This is how long it's been since I got here. Ha ha ha ha. Javascript, right? Yeah, so... Do the implementation for this to make this test pass? Well right now it is actually passing because it difference null by default. So maybe I'll write another test for... Make it return zero. When I have maybe only one number in the array. Okay, that's fair. Let's say... Yep, run it. For some reason it's still passing. I feel like I should have stuck with Javascript now. Ha ha ha ha. Can the master in the front seep? Did I save my calculator? Amazing. Master knows. Okay, so let's write the implementation for the sum. So I'm going to write the stupidest thing, which is to return one. But my first test failed. So I'm going to do something proper now. Fix the test. Fix that. Yeah, so the first test passed because I was returning one directly. So now I'm just going to be lazy and jump to the... Oh, sorry. Yay, my test passed. Properly now. Okay, so that's kind of like the first style of pairing that... This is mainly the style that I've been doing most of the time. Another one that we kind of taught in TW is ping pong. That one's really done when you do TDD. But then again, doing TDD in a disciplined fashion is also kind of difficult. So I don't do it so often, but I can just demo it. So the idea of ping pong is that you just... You write a fielding test. You run a test, see them fail, and then you pass it on to your partner to write the... To make the test pass. So right now, I'll just go ahead and implement a new test case. Oh, I'm so sorry. Yeah, sorry. Vim. Sorry, I'm doing Java. Actually, it's going to pass already, but... Yeah, that's all I want to say. I can implement another method. Yep, so this one I kind of was lazy and jumped the hit straight away. So I'll implement a fielding test for a different method now. Maybe average. So I'm just going to be lazy and do a direct kind of... Not test for any edge cases, so do a very straightforward one. No, no, no, I'm not like... How am I going to summarize the test? I don't know what I'm thinking of. Yeah, I did. I said that. Yeah, so I'm going to... I'm writing the test, the fielding test now. Yep, so... I think that's clear for me. So now that I've written the fielding test, Denise is going to implement the method and make it pass. Because it's TDD-style. So I'm just going to write the minimum code and make it pass. Oh, there. Wait, there's... Yeah, correct. That's right, my linter is very angry. So now I write the test. Describe. And yeah, there. Light 18 and not... Light 18, nice. This one. No, no, it's not, it's not. Yeah, sorry. We wrote the block in the wrong block, I'm sorry. But, yeah, so you get the idea. It's like write the fielding... Write the test, watch it fill, write the implementation, watch it pass. Obviously this is a very stupid implementation, but you'll get the TDD one step at a time. And with that, that's about all for my talk. Thank you very much. Do you have a question Steve? Yep.