Pair Programming after the Pandemic and Beyond

Speaker 1: All right. Well, good afternoon, everyone, and welcome to Django Khan. Welcome to my talk. I'm very excited, nervous, but very excited. My name is Tiny Phelps, and I'm here today with my colleague. Tobias McNulty and we will talk about peer programming after the pandemic and beyond. Um, this is a little bit about myself. I'm from Chicago, Illinois, in the United States. Um, I am a software developer at Cactus. Um And I love uh electric music and house music, just in case anybody loves that. I really love it, okay?

Speaker 1: Um, all right Alright. Um and let's like to Tobias introduce himself, I'm sorry. Um

Speaker 2: taking it from Take care of my

Speaker 1: No you have to

Speaker 2: Okay. So yeah, I'm Tobias. Um uh I've been using Django for almost longer than I can remember at this point. Um and I'm a member of the Django ops team and I'm super excited about pair programming and uh happy to be here uh with you all uh this week.

Speaker 1: All right. All right, enough about us now. Let's get into the nitty-gritty. Okay. All right. By show of hands, do we have any first time s speakers at any conferences like or is anybody is this their first conference that they're speaking at? Anybody? Ah, may the force be with you. Cool. All right. My initial plan for world domination was to make Django Khan Europe my first time speaking at any conference. But the universe had other plans for me. My colleague Tobias here was supposed to deliver a talk at Django Con 2023 2023 in Durham. But he got sick the week of the conference and was not able to present.

Speaker 1: And instead, a couple of his colleagues, a couple of us got together, paired and pr um got together and pulled together and delivered the talk for him. So crisis averted, people help helping people, and we took care of that. So this isn't my first It's it's technically my first, but not really. So that is um my spill on that. Okay, so what is pair programming? Well, tech the technical definition is that pair programming is an agile software development technique where two P two or more programmers work together. at one workstation. So the driver is actively writing code while the other is navigating, reviewing lines of code for errors

Speaker 1: and suggesting improvements. They may even be considering the big picture of the code base. During and after the pandemic, remote work exploded on the scene. So not to fret, pairing and collaborating can be just as effective online or remote as it is in in person. Here at Cactus, we are doing a little bit of a reimagining or remixing, if you will, the original definition of peer programming. So we are leaning more into and focusing more on the collaboration element of pairing, not just for computer programming. But all things technical. We found that there can be other types of work that benefit from collaboration and pairing with a partner.

Speaker 1: One thing that I love is collaboration. Collaborative ticket writing. I don't know about anyone else, but I do love a ticket with clear acceptance criteria. And collaborating, pairing with um our team makes for a much, much more detailed ticket experience. And I know we all love that. But fixing extravaganza, that's not a technical term. That's a term I made up myself. It's something that we do do at Cactus. This has proven to be really effective for s our small team at Cactus. When we're scrambling to deploy after QA has done their due diligence, we have um often gotten together with um front-end, backend , developers QA, and we hop on a Google Meet and just power through.

Speaker 1: bug fixes together and it so because we we have tight deadlines to meet. And I love it it's a sight to see because you have everybody just going at it, you know. I I've got one that works well under pressure to bias this. So it's like a It's just like a hodgepodge of people doing what they need to do. Okay. Alright, so uh bus factor. I heard in the the previous um talk that the young lady spoke about bus factor. That's weird because this is the first time I've been hearing about this bus factor. Um hearing also decreases the chance that you your project is derailed by bus factor Full disclosure, I didn't know that bus factor was an actual term.

Speaker 1: I was familiar with the concept because we all know we can walk outside and get hit by a bus, I mean in the butt, but I didn't put the two and two together, didn't know that there was an actual name for it. So if anyone else isn't if isn't familiar, bus factor is a term used to describe the number of people who could be run over by a bus before your project would be in danger of a failure or have some type of issue. The smallest possible bus factor would be one, meaning a single person is indispensable to your project, and that is not what we want. By pairing, critical knowledge is not siloed with individual developers, therefore mitigating the risks associated with anybody leaving the project.

Speaker 1: And that's what we want. PR reviews. Sometimes they I I get a little anxio anxious being a newer developer when someone of Tobias's caliber is looking over. my code. However, I love to pair up PR reviews because the real-time feedback has been so instrumental in my growth as a developer. Um I've been lucky enough to work with developers who are patient and don't really mind explaining or sharing their thought process when making comments on my PR. You know, I do like I come to a lot of the senior developers

Speaker 1: Like this is my level one code. Could you help me get to level two? And I've been very, very, very pleased with most of the responses. Okay. So oh that's my that's my beautiful pit blue Graham. I love to pair with him. Um he's 65 built 65 pound pity, yeah. Very, very cool to pair with. And if he could talk, I'm sure he would ask, why are we pair programming and not playing in the doggy pool? Well, here's the reason. Pair programming, improve code quality. Two heads are better than one most of the time. Pairing facilitates continuous code review, reduces bugs, and enhances

Speaker 1: overall code quality. Knowledge sharing, one of my favorite. Caring fosters knowledge exchange, allowing team members to learn from each other's expertise and experiences, and enhance collaboration. Working together promotes communication, teamwork, trust, and shared ownership of code, which leads to faster and more effective problem solving. All right. Best practices. So you want to establish clear roles. Um Who will be the driver? Who who's the ne who's navigating the journey? You know, some people like to um stack overflow

Speaker 1: an issue uh better than others, like they can do it quickly and or Google quicker. So that person should pop possibly be the one that is is navigating. But make sure you know who's doing what so you don't step on each other's toes. Setting goals. Setting goals and expectations. So define clear objectives for each session to stay focused and productive. Because if you're pairing with someone that you enjoy working with, you're possibly sharing that same key. Curiosity and that same childlike wonder. So this could be a blessing and a curse because it can become quite easy to go down a rabbit hole, a technology rabbit hole.

Speaker 1: There's so many libraries, so many frameworks, so little time. So you you want to make sure that you stay on task because if you don't it the pair programming might be fun, but not very productive if you're not really focused on the task at hand. And keeping an open dialogue. So don't be afraid to to to be vocal, you know, if it's not working. Cultivate and try to cultivate an uh an environment where constructive feedback is encouraged. and value. Not just any old feedback, constructive, you know, like, you know, don't tell me, oh, Kenya, black isn't your color. Who cares? I whatever. I want to know what's wrong with my how can I improve my code.

Speaker 1: And remember to take breaks. That is important. This work is mentally challenging. I'm not gonna care when I'm hangry, irritable, sleepy. I just can't do that. It's not gonna make a good session. I find that when I take care of myself, it makes it easier to take care of others. So make sure that you're ready to do this work. Alright. And I bet you're thinking the same thing that um the cactus intern Graham here is wondering. How do I get started? Well, let me turn it over to Tobias and he will talk about how to get started with pair programming. Uh

Speaker 2: cool. Yeah, thanks so much, Kenya. I'd like to kick off with a quote from uh another one of my favorite people to uh pair with uh my uh longtime friend and business partner, Colin Copeland. Um he wrote that uh For me, passing the baton is immensely helpful. I might take an idea to a certain point and then run out of steam, and then my partner might see the next step and jump in to find a solution and it prevents us from getting blocked. Uh much of the writing on the internet that talks about pair programming describes you know two people maybe using the same computer, and when they want to switch roles, they uh have to pass the keyboard. back and forth or try to explain uh you know what is

Speaker 2: is wrong with with what's being typed. Uh new tools uh we found um and you know we were sort of sort of forced to try them during the uh pandemic you know because we no longer or had the opportunity of uh working together in person. Um and these you know tools, uh which we'll talk about in a second allow programmers to share a single uh development environment, uh, you know, either locally or remotely. uh each from their own workstations. Um you're probably familiar already with some of these tools. Uh two of the popular development environments uh for uh distributed pair programming are uh VS Code's live share And uh PyCharm's uh code with me. Um

Speaker 2: plug for the DSF, if you have not yet seen, PyCharm is on sale right now for 30% off, and all of that revenue uh goes to the Django Software Foundation, so check it out if you're interested in. In uh PyCharm. Uh but both LiveShare and Code With Me include um you know pretty similar features such as uh you know real-time collaborative uh you know file editing. So if the driver uh gets stuck and isn't sure what a particular uh you know function or class is called, uh the observer can jump in and simply type that into their editor instead of uh you know having to spell it out on a video call. Um on the other hand, if the driver is you know moving very quickly uh and the observer is you know more in a capacity of learning about the code

Speaker 2: base uh they can follow uh the you know leader if you will and um see what they what files they're looking at or editing um during the session. Shared terminals are also super powerful. They you know likewise you know help if the observer needs to jump in and uh type out a new command um for the person that is um driving at that time. When using chair terminals uh pro tip, I still really like to keep a uh markdown document with all the commands that um you are typing and you know type them there ahead of time. Uh this serves a couple purposes. Uh number one, it helps everybody in the session understand what's happening.

Speaker 2: And uh number two, it can serve as a great log for a uh readme or other you know documentation if you would like to you know put that together after uh writing you know whatever it is that you're writing at that time. Code wise. Um VS Code uh super cool also uh by default will uh share with everyone in the session any uh ports that are opened on your uh in the terminals in the uh VS Code session. So uh other members of that uh live share can you know connect to your Django run server, for example, and you know help to test or uh you know debug bug debug the application uh At the same time.

Speaker 2: And yeah, Keny already mentioned that a couple times we've had these marathon bug testing sessions at Cactus where we'll have people from uh development and QA and user experience backgrounds all working to together on a single environment. And it sounds chaotic and time intensive, which it is, but it can also be quite productive. And everybody that we've uh found participated in this really enjoyed it and would So yeah, show of hands. How many people are familiar with creating uh git commits with multiple authors? A handful. Okay, great. So yeah, this is one of my favorite things about uh pair programming, and that is uh you know

Speaker 2: keeping a history in the log of the code that was pair programmed. And to do this, you add a a code Dash authored by line to the bottom of the commit message. VS Code at least will automatically do this for any members of the current live share based on their GitHub logins, for example. Um and I think this is a good thing to do because it you know both uh provides attribution for the code um to everyone who helped to write it, uh and then can also be additional context uh you know six months, twelve months from now if uh you're trying to figure out uh you know some some detail about the code that was written at that time. Um So yeah, for better or worse, uh I guess no

Speaker 2: no pair programming talk uh today would be complete without at least a brief mention of Copilots. Uh this is you know Microsoft's developer-focused AI tool for uh uh you know integrating with VS Code and providing some you know shortcuts and code suggestions. Um and it it advertises at least that it can uh you know help find other parts of the uh repository that are affected By the changes that you're making. I still default to preferring a human pair programmer when I can find one, but Copilots might be handy for helping with lots of boilerplate code or other repetitive tasks. Kenya mentioned to me that she would recommend Copilot more for mid or lead programmers,

Speaker 2: less for junior programmers who may not have the context to evaluate the solutions that Copilot proposes. I did test copilot in preparation for this talk, and I was not very impressed with its code suggestions. It kept telling me that it uh it didn't know anything about the files in my repository, uh, which could have been user error on my part but I I thought that was the whole point that it had that that greater context. So maybe I was doing something wrong and someone has a suggestion. It did give me uh it did tell me how to use the uh search tool in VS code to look for what I was looking for, which I found somewhat amusing. Um one one area where I think it it did a great job was uh writing a unit test.

Speaker 2: Um you can point it to a function and ask it to write a test for you. And Uh it got a lot of the boilerplate out of the way and it even came with a decent dock string um that helped me get started Um and yeah, before closing we we do want to make clear that um programming is not for everyone and it's it's not for every problem. Um working closely with somebody can be uh can be really awkward. It is I mean totally real and valid to uh feel hesitant about you know bringing someone in, you know, so close to how you work. Um for me, um for example, I'm uh can be embarrassed sometimes by the number of typos that I make um with an audience. Uh And when possible, you know, it can help to have a pre-existing level of trust

Speaker 2: with the person or to pair with somebody who you already enjoy spending time with. On the other hand, if you haven't worked together with someone before, it can be a great way to hang out and get to know someone in a casual environment while you're trying to solve a problem together. When working remotely, it can be a substitute for the you know office uh water cooler tuck, um but our main advice is just to keep it uh low stress and casual. Um Programming can also be, like Kenya was saying, time intensive and exhausting. Um you know, focusing together on a single problem for an afternoon um can take a lot out of you. Um sometimes I might like to organize my thoughts ahead of time before bringing someone else in

Speaker 2: Or if I don't have any idea where to get started, um, you know, maybe I'll brainstorm briefly with someone ahead of time to um try to figure out what path to go down. Um and the the key value we think is just avoiding, you know, time spent um going down the wrong path up front. You know, me, myself, I might get super excited about this certain idea and go forward with that for a couple hours, but if I was pairing with Kenya or Colin, you know, perhaps they would see a a different aspect to the problem and help guide the project in a different direction. Uh the biggest um challenge that I found with programming is just that it's a you know it's a new thing and a a lot of people have not um tried it before and you know really invested in it. It might take a few tries to find the right fit,

Speaker 2: but done well. You know, we think that you know pair programming should feel fun and uh productive. Um it can also help foster uh inclusion on the team by helping to you know bring new people into the projects. If you have tried it before and had a bad experience, we would encourage you to give it a try with someone else or on a different project or problem. In the end, our programming should foster this supportive team culture that we're talking about and create an environment where collaboration is valued. And uh mistakes are seen as opportunities for learning and improvement. But uh before all the managers in the room uh decide to uh mandate

Speaker 2: that everyone uh pair program for eight hours a week, and you know keep in mind that But it must feel uh you know productive and and valuable to the people uh doing the work, otherwise it it will be uh counterproductive. So yeah, ultimately we think like Kenya was saying that this uh mentality can be applied to all types of work. Uh in their article, um, for example, about um you know writing uh blog posts together, uh Jacob and Sumana wrote Find a partner who wants to make progress on something we think someone you're friendly with with similarish goals is best. So thanks so much.

Speaker 1: Stay connected and keep pairing. We're trying to do something cheesy and let us pay. Thank you.