The Power of Pair Programming with Shopify VP of Engineeering Farhan Thawar

If you click on the Options button instead of the— you can still present full screen, I believe.

Okay.

And drop Options at the top of your screen. You'll see you are viewing full screen and then just drop down View Options and hit Exit Full Screen.

Yes. Yeah, I don't see it.

What about if you hit participants at the bottom and then—

if I see participants, I can see everybody here.

Yes, that's correct.

Okay, wonderful.

So as I admit everyone, you'll be able to see them.

Okay, yeah, I can see the message. I can click on messages and see them, I guess. Anyway, Amelia can help.

Fantastic. All right, I'll give it one more minute and then we can go live.

Oops.

All right, I'm going to start admitting attendees.

Great.

Alright, good afternoon and good evening wherever you are joining in the world. You have joined ZA/STR Annual and this is our roundtable session with Farhan Tawer, the VP of Engineering at Shopify. Looking forward to an excellent session. Jason M. Lemkin this afternoon. Just a few housekeeping items. We are live streaming this and we'll be admitting in more attendees as the session goes. Alright, this is an interactive session. 30 minutes, it flies by. When you did join, your video did pop up. That was on purpose, but you are muted. And this is to encourage interactivity, to ask questions. There are two different ways that you can ask questions. One, with the raised hand icon, that is an audible option to ask a question to Farhan. Or you can use the chat function below and drop your question, your statements, or your ideas as well. 30 minutes does fly by, so I know we want to dive straight into this. So thank you so much for taking time this afternoon to join. I'll hand it over to you, Farhan. As Farhan, here we go.

All right. Hey everybody. So my name is Farhan Taur. I'm currently VP Engineering at Shopify after Shopify acquired my last company and here to talk about pair programming. I actually really like this, the subtitle here, Simple but Not Easy, because pair programming is actually pretty easy to explain, pretty easy to understand. However, what I found over the last decade or so as I've been practicing pair programming is it is of varying levels of difficulty to actually implement. So simple to talk about, simple to understand, very easy to see the productivity gains. However, it is hard to implement. So happy to chat with folks about that. So I'll get into some of the content first, and then what we'll do is leave the, you know, majority of the time for questions. So first off, pair programming, I'm going to talk what it is, about what it is, um, and a few anecdotes. And I do want to talk about, specifically, if it's so good and so effective, why doesn't everyone do pair programming, right? Because if it's, if it's a known, obvious thing for, um, productivity, why don't— why doesn't everybody just pick it up and use it? So first off, what is pair programming? Um, the picture there actually is an article from the New York Times. So it is, um, amazing that the New York Times picked up an article about pair programming. But the idea is that You have two developers working together to accomplish the same goal. And the same goal is typically to build high-quality software on a predictable schedule in a way that allows knowledge sharing and high productivity. Now, what's different about pair programming than just sitting beside somebody, another engineer, is that you are on one computer. So it is very much like flying an airplane. You have one plane, one, one actually, uh, two sets of controls, but one goal in mind, get to the destination safely. But you actually have two people and two sets of controls that allow you to control the plane. And actually, what you'll see in an airplane cockpit is a pilot and copilot working together to actually get to the destination. The same thing happens in pair programming. You have two people on one machine. So of course, only one person can type at once. But by having two keyboards and two mice, they can go back and forth between driver and navigator. So that's really what pair programming is. Now, one thing that always comes up in pair programming is they say, well, if you're pair programming, then aren't you going to lose a lot of productivity because you got one computer instead of two, right? You usually have two engineers or two developers writing code at the same time. And there is great research. Actually, what I used to say, um, before I found a lot of the studies was that pair programming works in practice. I'm just not sure if it works in theory. And the reason I would say that is because it's hard to prove developer productivity using, you know, actual, like, experimental hypotheses. However, what we do see in practice is that it's extremely effective. But I have stumbled across some, some survey, some research data. And what's interesting about this data is that what it shows, it shows that it's not 100% slower, which you would expect. It's about 15% slower than regular 2 engineers working on a problem. However, for that 15%, what you get is higher design quality, lower defects, lower staffing risk, enhances technical skills because they're learning from each other, improved communication, because you're talking a lot between each other. And of course, um, it's— engineers tend to be happier by pair programming. So there is now research showing that pair programming is more effective along with, of course, all of the practical advantages of pair programming. Happy to share this study after as well. So, and then what do I know? Why am I talking about pair programming all the time? Well, I think, you know, I'm quite qualified. I actually ran the largest pair programming office in the world with about 120 pairs. So that's about 240 engineers. There's a picture before we got acquired. And then we did get acquired by Pivotal Labs, which is known for an extremely disciplined process of agile development, including pair programming. The name Xtreme Labs, which was the company I was at, was named after extreme programming, which has one of its main tenets as pair programming. This is just a picture of our team. So simple to talk about, but hard to implement. Why? And this is actually, I would say, the crux of a lot of questions that come in when people ask me about pair programming. I would say there's a few reasons. The, you know, one of the reasons is developers have to work synchronously. So this idea of having ultimate flexibility Coming into the office whenever, or even working remotely whenever you want, is hard to do with pair programming. You do have to work synchronously, which means at the same time. It does feel slower because you are blocked, right, from using the keyboard because you've now got two people who are working together to get to the goal. And like most things, it's hard in today's COVID world. It is better in person, like a lot of things. Now, there are some amazing, amazing remote pair programming tools. Uh, the one we use at Shopify is called Tuple, T-U-P-L-E. And what's great about it is that it really focuses on two things. It has a great representation of the UX of what you're building. So you've got your editor in front of you. You can have two people pairing and one observer as well. And it shares an audio and video stream if you want, but it does focus on the remote engagement part. Now, what's amazing about pair programming, and I talk about this a lot as well, is that if you look into the research around the NBA and free throwing, it's very similar. In that the underhanded free throw is actually known to be more effective, higher accuracy, easier to get the ball in the basket. However, people don't do it because, you know, in a lot of ways they feel dumber doing this thing that is more effective. It's very similar with pair programming. It feels slower to have two people on one machine. However, it turns out to be more effective. And this is an interview snippet from Shaquille O'Neal, who is a Hall of Fame basketball player, but notoriously bad free thrower. And when the data was shown to him that it's better to use, uh, you know, throw underhand, he actually said, I don't want to do it because it's boring. So imagine somebody who gets paid multiple millions of dollars per year to do something as a job, but will not do it because it is boring or looks dumb. Very similar to pair programming. It does feel odd to do or feel slower, however, is more effective. Um, and this is actually one of my favorite tweets. About pair programming, because what a lot of people feel like is that because I'm being blocked from typing, right? Because I'm being blocked from typing, I'm actually going to have lower productivity. And what's great about this quote is, is that it's not about keyboard throughput, right? Having 2 people on 2 machines and just furiously typing, the keyboard is not the limiting factor. If programming was a factory, the limiting step is not, uh, you know, hands on keyboard. The limiting step is writing elegant, readable, maintainable, flexible, performant software. And in many cases, when you pair, you'll actually get less code, which is actually what you want, right? Software code is actually a liability. What you want is to produce the output, which is high-quality software. That doesn't mean lots and lots and lots of code. All right. So that's— I'll leave that up. Or actually, maybe I'll stop sharing. And we can get into the discussion portion of the talk. I'll open it up for questions. I've got the chat here. So a couple of ways to ask. You can actually ask over audio, or you can raise your hand, or you can type into the chat if people have questions about pair programming.

Right. So I'll go first. I'm Ayaan Nordjuk. I'm actually from New Zealand.

Hi.

So for me, it's early morning. [Speaker:JASON_M_LEMKIN] I am really curious about how you start the process of extreme programming. I assume you don't throw them in and then let it go. How do you do the first steps?

[Speaker:JESSICA] Sure. So really good point. So what I would do is the following, and it's— I've seen it be successful, is one is you should actually share a lot of information about pair programming first to see if there are folks on your team who are interested. Because what I've noticed is Sometimes you've got a 30-person engineering team and people are really excited about pair programming and they try to like jam it into an entire team. I don't think that will be successful, not just with pair programming, but with any type of process change. What might make more sense is actually getting a few people excited about it. So whether it's in person or remotely, I would look for a couple of engineers who are interested in trying it, seeing what works and, uh, seeing who's interested in it and then trying it for a few hours a day. Now there's a lot of shops that would do pair programming for 8 hours a day, which is actually quite effective. However, I don't think that'll work in every environment, in every company. Instead, what you could say is, here's a tool. Let's go over some materials around pair programming and try it for between 2 and 4 hours a day with just one pair of engineers. Figure out a time that overlaps, or maybe a problem you want to work on together. Use a tool like Tuppel, see how that goes, and then take feedback. Oh, you know what worked? What worked was we did it after lunch, or what worked was we focused on this problem. And then only then would I then start investing in trying to make it, um, something that's more standardized across the team. The other thing that have people have to be aware of, because it's so intense and it's also very distraction limiting, meaning people can't like go check their phone, check Twitter, check Reddit. Um, they tend to get tired because you're intensely focused. So, um, what I would say is make sure they don't go more than 8 hours a day, but usually start between 2 and 4 hours. Only then would you want to have that pair talk to the rest of the team about what their experience is. It's also very interesting. It's almost like, I would say, like surgery. You don't want to leave halfway. You kind of want to do it for like a month or two before you kind of give up on it, because it is weird, right? It might feel like slower for the first week or two as people get used to it. You do want to try it for a month or two before you start saying, okay, now we got used to it. I'm learning a lot. I enjoy this type of engineering.

Awesome. Thanks.

Cool. No problem. All right. I'm going to read the next question. It says, how do you convince a diverse team to try this out? So what's interesting about pair programming in my experience is I found that the teams tend to be more diverse off the bat. Because what happens is, is that you get engineers who are senior and junior. I had— in my case, we had many more women pair programming than we did— like many more women on our engineering team than we saw previously when we didn't do pair programming. So I don't think there's any different approach to a more diverse team. The only thing I would be careful of, and some of the research disputes this, but in my experience, I have found that a junior-junior pair doesn't work so well. I have found senior-senior pairs to work well. I have found senior-junior pairs to work well, because even a junior engineer who comes with an open mind and a fundamentals of the computer science background can contribute. But I found junior-junior doesn't work as well. So I don't think it's— different than what I just mentioned, which is start with one pair before you start going with more pairs than that. Let me check. I'll go to the next question from Alan. I find that developers want to figure things out on their own. How do you sell people on pairing up and creating a culture where pairing is the norm? So you're right. What you can do in this case is that engineers do want to find things out on their own, but engineers want to learn. And just because you're reading it online versus learning about it from another engineer doesn't— lessen the learning. Actually, it increases the rate of learning. So my sell to people is, well, if you want to learn and level up, um, it doesn't matter whether you're reading it or learning from someone else. I actually find that learning from someone else actually tends to be more effective and it's faster and you can ask questions. So if you focus on the learning component, I would bring it away from the by yourself, um, part of that, because for me, it's all about what's the rap, what's the fastest way I can learn. And the fastest way is usually like apprenticeship. Working with someone in high fidelity. And so that's my sell for that. From Louise, what are the limitations to pair programming? Well, one is that I find that it is tiring at the beginning, but you do get used to it over time. Another limitation is I found that in 5% of the cases, there can be a personality conflict. So sometimes you might really find people who are, have a, have a, have a something inherent in their personality, which will make them not pair easily. However, I find that it's pretty rare. Outside of that, some of the limits, like I mentioned before, where you have to work synchronously, right? It's really hard to say, I'm going to work at this time and I'm going to work at that time and then to pair. It's almost impossible. What kind of results do you have in terms of productivity? So, yeah, so there was some research shared earlier which said that you do see about a 15% productivity drop, but you do get better architectural design, less hacking. More knowledge sharing, higher throughput, less bugs over, over a longer period. From John Koren, aside from pair programming, what other quick wins could a small dev team have to work more effectively in building a high-quality product? All right. This is— I love this question because it's not just about pair programming. It is about a lot of things. And I would say the next thing that I would look at in engineering team is I'm a big fan of weekly demos. So what's amazing about weekly demos is this idea that Everybody shows or tells about something that they did that week. And it is really almost like the homework's due every Friday. And what's amazing about it is it, um, it doesn't have to be a show, right? You might not, you might have refactored something and you can't demo it, but it can be a tell. So everybody kind of talking about what they worked on that week really shows you a couple of things. One, it encourages everybody to share like what they think the top 2 or 3 things are. And two, it encourages a feedback loop so that people can ask you questions about what you worked on as well. So I find that, that encourages people to talk, but also helps you learn about what everybody else is working on. So for me, demos and pair programming go really, really go hand in hand from that perspective. All right. From Thomas, how would you compare the success of pair programming with or without sitting together physically? That's a good question. Um, since we've gone remote and we use a tool, like I mentioned, called Tuple, um, what we found is of course the usage of the tool has gone up because now people have no choice but to use the tool. Versus pairing in person. I would say the differences are similar to what you have, what would happen over like a Zoom call versus being in person. You do lose some cultural nuances, right? You're not together. You might lose out on some of the things you get in a higher fidelity medium, like being in person, but Tuppel is really, really good. And when people use the tool, we do find that pairing over Tuppel is better than not pairing at all. And so what I found is, um, You can still get a lot of the productivity boost by pairing even remotely. From Carlos, do you suggest that 100% of the code is written in pairs or only complex code features changes? I'll start with that first part of the question first. So in my experience, you can pair on almost anything. Actually, one example I have from Pivotal is we kind of tried to turn it on, turn pair programming on its head and say, you know what, let's stop pair programming. What would we lose? And we said, well, let's stop pairing on like emails to clients. Let's stop pairing on reprioritizing the backlog. And what we found is it wasn't just the programming part. It was actually all components of software development that were very, very effective via pairing. So it was, so we expanded it to be even beyond pair programming. We saw it from, you know, I used to do invoices with someone in finance, pairing, meaning we'd sit at one computer and do the invoices. Designers used to pair, PMs used to pair. So I actually think there's a lot of effectiveness happening by just having 2 people on 1 computer, just like I mentioned, having 2 pilots in 1 cockpit. It doesn't have to just be about pair programming. So I think, definitely complex pieces of code. I've seen in some engineering teams, they say, if you're going to work on this part of the code, you must pair programming, must pair program. That's a great way to get into pair programming. But I don't think there are places where, you wouldn't get a benefit. That being said, there are some teams and some cultural norms whereby you might not want to pair 8 hours a day. However, it is super effective if you can get your team to do that. The second part of the question is, are some people— oh, right. Yes. Are some people writing documentation? What do you think? So if you can't pair or culturally don't feel like you can pair in person or even over Zoom, you could do like what's called side-by-side pairing, which is side-by-side programming, which is one person— each person has their own computer. And from that perspective, you get some of the benefits because you're talking, you're not getting distracted, but you're not pair programming. If one person is writing documentation and the other person is programming and they have two machines, that's not pairing strictly. However, there's probably some advantages to being synchronously together and talking, but I wouldn't call that pair programming. All right. From Thomas, do you see a total minimum number of dev team size necessary for pair programming? In 2015, I started my own company with my own money. Like, I didn't— it wasn't funded for the first 9 months. And my first 2 engineers were pairing. So you can literally start pair programming at any size company. It doesn't have to be a certain minimum size. Even 2 engineers, even a founder and an engineer, even a designer and an engineer, like any 2 people can pair on anything. It is extremely effective. Don't forget, the output of any sort of process is not numbers of lines of code, or for a designer, number of designs. It's actually working together in collaboration to build a high-quality product. So you may have less, what looks like less throughput in terms of lines of code or designs, but what you're building is actually higher. Um, you're, you're, you're working in a higher effectiveness and you're building higher quality output. right? So that's why that tweet, if we go back to the tweet, which says you're gonna have less lines of code, is actually a good thing. Or maybe you have less designs. That's a good thing because you have higher quality designs, right? There's that famous Mark Twain quote, which says something like, I'm sorry I wrote you such a long letter. I didn't have time to write a short one, right? Same thing is true here with programming and with design and with PMing and with writing emails to your your clients, if you're in a consulting business, it is about higher quality output. It is not about more throughput, more lines. So I don't think you need a minimum size. And I encourage people to try to develop higher quality output by pairing. All right. Next question. 15% loss in productivity does not make sense. Okay. People waste so much time. I would think working together has a huge productivity increase. So yeah. So, so here's this, and this is exactly the misnomer. So What I always say is from a pure finishing— so the study was the following. They took two sets of, uh, they took two teams and Team A was pairing and Team B was not pairing, and they had to accomplish the same programming goal. And what they found was, yes, Team A, which was pairing, was 15% slower, meaning they took 15% longer to achieve the goal. But what they got in in trade for that was lower defects, better architecture, engineering happiness, less knowledge silos. So they did go a little bit slower. Don't forget, they didn't go 100% slower. They weren't twice as slow. It wasn't like it was 10 hours versus 5. They were slightly slower, but they got all these advantages. And if you go to any engineering manager in the world and you say, for 15% cost, you get all these advantages, everyone will take it. So you're right, just distraction alone, what I have found is that people tend to finish faster with higher quality. I think in the case of this study is they didn't include quality in the study. Like they weren't, they didn't finish with the same level of quality. And if you had to finish with the same level of quality, I will say pair programming wins every time. All right. Next question. Does it create silos instead of teams? All right. So good question. And I didn't address it in my talk is that the best thing about pair programming is you can change the pairs. So when you've got pairs, you can move people. So here's a good example. When you've got one pair working on something and you want to increase the team size because you're running behind on the project or things are going really well and you want to add engineers to your team, it's really effective because what you do is you take the original pair and you split them and you add two developers. And now, because the original pair has all the context, you can now ramp up the other two pairs. It's the only time I've seen in software development where you can literally get a linear speedup, which means that when you go from 2 engineers to 4, you can actually go from, you know, if you look in terms of story points, if you were delivering 10 story points a week, you can literally go to 20 story points a week because the original pair has so much context. Now, when the new pairs are pairing, you can literally double the throughput. So I've seen that happen time and time again. And what I've seen also works super well is when, One person comes from another team and you want to onboard, you have a new employee. When somebody is leaving the company, when you have interns, there's so many ways to make this work that, um, having two engineers break up the pair and work, you're now spreading the knowledge. Actually, when I was in my startup, we had about 5 or 6 pairs. Every few months we would switch the pairs around and now you had the entire company over time, which knew the entire software stack from the front end to the back end, to to mobile. And that very, very rarely happens when you've got a team that is not pairing. Because what happens is, unless you explicitly say, all right, Simon, you switched places with Rebecca and you've now got to take on the backend and the frontend, it— that very rarely happens because it's really hard to ramp up. But instead, when you're pairing, you can now switch people around because you leave one set of pairs, you leave one person in each pair, you swap the other people, and now they're pairing. And then you can move people people around is really, really effective from that perspective. All right, more questions. Let me see if I missed anything. Sorry, I'm talking really quickly. Other questions from folks? Now, one thing I didn't talk about too was the— you can really pair people from different disciplines. I have paired data science people with engineers. I've paired QA people with— frontend developers. I paired frontend and backend, database engineers. There's, there's, it's really powerful to see how another person in another domain thinks. And so working a data science engineer with a, you know, an Agile engineer is super powerful because you can actually learn about each other's discipline. Oh, here's another question. If a team hasn't reached a high level of maturity in their dev process, do you suggest pair programming or is it better to implement other practices? So good question. What I have found is pairing can happen at any stage of development. Again, don't forget, I started my own company. We didn't have any real development process nailed. We hadn't really figured out what our product was going to be. We were still in the ideation stage. But what we found was by pairing, we got— we had really good questions being asked. We had frontend and backend people working together. And so they were building out this codebase without any silos. And it was really effective even early on. It didn't have to be that you've got like a laid out process. In many ways, the more Wild West it is, the better for pair programming, because you, you don't have much of this documented. You don't have a process solidified. And so by people working together in the early stages, you're really trying to figure things out. You're asking questions, you're asking questions to the founder. Maybe, maybe one person is a founder working with someone else, and you're really asking these early questions. Now, Now, you might decide in some parts of that process to split the pair. That's fine too. You can still side by side. I don't think it has to be that rigid at the beginning, but by pairing and unpairing, you are building— you are breaking down that knowledge silo and reducing the amount of assumptions being made. So I still think you can start it at any part of the process. You don't have to wait till it's mature. And anyways, in many companies, it's hard to know when it's mature, right? At Shopify, we're like 5,000 people now. I don't know if people would say any part of the company has reached a plateau, right? We're still building things. We're still talking to merchants. We're still trying to build things in high throughput. And we do pair program at Shopify, right? We have a standardized tool called Tuppel, and we do it for complex parts of code. Some teams exclusively pair, other teams use it for other— for onboarding. So it totally depends on which teams and how they want to adopt it. No blame games during performance reviews. Good question. So What's amazing about pairing as well, and this I didn't talk about yet, but it is a, it's a secret management trick. So what's amazing about pairing is because you're working, you know, let's say you pair even 4 hours a day with one person. Even actually, if you paired 4 hours a week with one person, you would have extreme intimate knowledge of each other about how each other works, how you think. And so the peer feedback delivered during those sessions and potentially after those sessions is extremely effective because Imagine, you know, today, if you work with people, you probably work with them in an asynchronous way, right? It's very rare that you're working with them in a high, high-fidelity way synchronously, unless you're in a meeting or something. But even in a meeting, you're not poring over code as in a detailed way as you are in a pair programming session. So when you're pairing, it's high fidelity, high intensity. And because of that, you're now actually going back and forth, and you're giving each other feedback. In a way that's very constructive. 'Cause you're saying, have you thought about this? What about this API? Have you thought about this other thing? And what I found is when people are intensely working together, you'll give each other great feedback and high throughput, and it will make both people better. But if one person's not really jiving, right? So let's say there's a new hire or, you know, somebody is not really jiving, you can give them feedback and you can effectively help them figure out if, what you're working on is going to work for you or your company. So here's a good example. You bring in somebody new, you've gone through the interview process. They seem to be great. You work with them. And after 2 or 3 weeks, you realize, you know what? It's not, they're not really jiving with our process. Maybe you move them from one pair to another pair. And then the same thing is true. You give them the feedback, but maybe they're not getting it. You might figure out in the first 90 days that maybe they're not a fit for your company, but you figure that out very, very quickly in a pair programming environment versus a non-pairing environment. And that's actually good, right? It's actually good for you to figure out early for for you to give them that feedback and for them to find a company that is more in line with what would work for them versus keeping them in for a year. I've worked with startups that are just 10 people, and sometimes it takes you a year to figure out if someone's a fit for your company or not, because you weren't really working with them in an intimate way. With pair programming, hopefully you can figure that out sooner and help them land somewhere which is more effective for them, right?

I—

the one analogy somebody gave me is you go to the gym and you ask somebody to bench press 400 pounds. Like, it doesn't really make sense, right? And if they can't do it, It's not maybe the right approach to just have them struggling with that bar for a year. Instead, it might make sense like, hey, go work in that company and then come back to us when you can bench press 400 pounds, because we're already this team that's working effectively. So what I found in performance reviews is that peer feedback is extremely effective in pair programming. You get it all the time. You don't have to wait for a 3-month cycle. You're getting it every day. Every moment of pair programming, you're getting feedback. You're going back and forth. Um, and that makes the performance review cycle more effective. You can manage people out more easily and you can actually, um, learn from each other and level up much more quickly. Also, ever tried it with more than 3 people? So the tool we use called Tuppel is it has an observer mode. So it lets you have 2 people pairing with 1 observer. And what's cool about that is you can have 3 people. The observer cannot type. They can, they can talk and they can observe. and they can, you can drop in. So what's amazing for me as a manager is I can drop into a pair, listen, understand what they're working on, drop into another pair so they can add me as an observer. There is something called mob programming, which is this idea that you could have more than 2 people. You could have a room full of people, one person typing and everybody like screaming at the person typing. So it has some advantages because you actually have this idea that more than one person might have an idea. It can be hard for the one person to kind of hone in on what they're focusing on, but I've seen it in the past. I haven't seen it remotely done. Maybe it would be like this, like the Zoom, and somebody has their screen up and everybody kind of yelling at them, no, do this, do this. But with one person typing, I've seen it more in person and it has its advantages. I haven't seen it done at scale. Cool. Last questions. "Do you have to convince your devs to move to the Mac platform as Tuple only works on Mac?" Good question. So yeah, we currently at Shopify use Macs across our environment. And so we use Tuple. There are other platforms. Some people use like Zoom, there's screen sharing platforms. Teamux is another one. I don't know, unfortunately, a lot of Windows ones. I know VS Code has a live option as well. I don't know if it works across Windows and Mac. But those would be the tools of choice. I did mention, like, a research study. You know, you can find, actually, a YouTube video of me talking about pair programming, which links to the research study as well. I think we're at time. Let me know if I should keep going or end.

We have time for another question, if you'd like to field one.

Cool. One more question. Any chance we could grab your email and check in with you periodically if we have questions? Yeah, sure. Actually, the best way to connect with me is on Twitter. I tend to get a lot of people messaging me about pair programming, and I share a lot of research there. So it is @fnthawar. I think that the SASTR folks also tweeted out this live streaming session with my Twitter ID. So feel free to ask me anything to do with pair programming over Twitter, and I will respond.

Thank you so much, Farhan. That is incredibly insightful. We will have this recording available as well, and thank you all so much for joining.

Thank you.

Thank you.