Pair Programming for Sustainable Deployment | Kris Fabick | Data Science Hangout

Hey there, welcome to the Paws at Data Science Hangout. I'm Libby Herron, and this is a recording of our weekly community call that happens every Thursday at 12 p.m. U.S. Eastern Time. If you are not joining us live, you miss out on the amazing chat that's going on. So find the link in the description where you can add our call to your calendar and come hang out with the most supportive, friendly, and funny data community you'll ever experience.

All right, with that, I would love to introduce our featured leader today, Kris Fabick, Data Scientist at Nissan North America. Kris, thank you so much for joining us today. I am so excited to have you. Could you introduce yourself and tell us a little bit about something you'd like to do for fun as well?

Sure. So happy to be here. I'm a longtime listener, I guess first time speaker. But yeah, I work at Nissan. I'm a data scientist. I've been here for about six years. And before I came here, I was a high school math teacher. So I did that for a decade. Super fun, just needed a change. And this has been great. I have a seven-year-old at home that I love to hang out with. She's my favorite person in the world, followed close second by my wife. And then outside of work and outside of family, I referee soccer games at a fairly high level. I do high school, college, all the colleges. So division, all the NCAA divisions, NAIA. And then I do semi-professional adult games as well.

That's so exciting. What is the best and worst thing about being a referee?

I love, I'm a team player. I've just always, I don't remember life before soccer. So I've always been really good at team things. I love needing to rely on other people and also them relying on me. And that's really no different as an official. It's just a smaller team. There's like three or four of us. But it's, it's, I love the teamwork and I love getting to meet people from all over the world. Soccer brings people from all different cultures and backgrounds. And it's super fun to have that experience. Yeah. The worst thing I guess is there's a lot of pressure sometimes at some of the high level games with everything being on video. We want to get all of our calls right. But like, there's a lot of scrutiny sometimes and sometimes things are not clear and there are judgment calls. And a lot of, you know, announcers don't always know the rules. And so sometimes, you know, you kind of get a bad draw on something, even though you've done everything within your power. And, and it really, as you know, someone like my whole job there is to be fair. And sometimes it feels really bad when I make a mistake. I'm humanized and I do make them, but sometimes it feels really bad when I make a mistake and it, you know, 35 people on a team, plus all of their fans are really angry for a while.

I'm mad at you. Okay, everybody, you heard it here. Be nice to referees. Some of my best friends are referees. If you don't know this about me, I used to play roller derby and in roller derby, we need refs all the time, desperately. So a lot of roller derby players also referee and yeah, it's a hard job and the sport doesn't run without them. So be nice to refs.

Pair programming for sustainable deployment

Okay, everybody, let's get a little context for what Chris does so that we can ask good questions in Slido. And actually the context building that I would like to do today is about Chris's PositConf talk. If you do not know Chris and his co-speaker, who is I think Kristen Carr, is that right? Yes. And she's on the call. Hey, Kristen. Oh, I'm such a big fan. I loved your talk. I would love it if you could both, if you feel like it, give a little recap of your talk. I will just say it was about pair programming, which is one of my favorite topics and it was a pitch for how pair programming can be a mechanism for sustainable deployment.

Fantastic topic. Chris, could you give us a little recap? Yeah. So I mean, it was a 20-minute talk. I'll try to make it a little shorter here. We really approached the talk with, we sort of had two things we really wanted to drive home because a lot of data science, you have these great ideas, right? But then like, how do you actually get them to your end users? Like that's always the struggle. And like, that's really difficult to teach in school because it depends on like a lot of specific tools that maybe your company has. But going outside of those tools, we wanted to talk about how do you get a business team to be able to deploy something successfully to another business team?

So we're very clear about the type of deployment that this is, right? It's not an enterprise level deployment. We work in supply chain. We're trying to deliver like a machine learning model to predict something to help another supply chain user make a better business decision, right? So we're not trying to like predict how many cars are going to be sold in some market for some other sales division, right? And so to do that, we're just, I feel like I'm sort of like the captain of like our little data science team here in supply chain. We've got like four data scientists at best and then a manager and then like, you know, we kind of do a bunch of other things. So we don't have all these enterprise level tools. We don't have this IS support. And so how do we get this tool out there and how are we going to maintain it, right? Because we don't have all those enterprise level tools and support, we're also responsible for that support. And so our solution to that, our team has been really successful in deploying projects using pair programming.

And we have come to learn in when we practiced our presentation that it turns out a lot of people don't know what pair programming even is. And so we needed to sort of define that, define what it isn't and what it is. We used a lot of really cool cat gifs to tell you what it is not. And that was super fun to research at work. But it is essentially just working with a coding partner. It is not necessarily like sitting side by side and like spending your entire day together, like you go to lunch together and you check your emails together, like that's not what we're doing. It's really a mindset of like, how do you work together with someone else so that you both create a redundancy in your project so that you both can address any concerns that come up. You can react quickly to a business need or change, both in development and then also in deployment, right? So it's the idea of building in human redundancy into your project so that you can safely deploy this thing to the business. And then you can still go on vacation because somebody else can cover when you're out.

So it's the idea of building in human redundancy into your project so that you can safely deploy this thing to the business. And then you can still go on vacation because somebody else can cover when you're out.

Right. Which is essential to peace of mind. But also there are so many, as a teacher, so I come from teaching too, as a teacher, there are so many things that learners and everyday users, even power users of R and Python, do not learn until they see somebody else do it. So you can be pair programming and somebody will click something or do something or use a keyboard shortcut. And you're like, wait, what did you just do? I didn't know that was possible. The way that you expand the things that you know in your skillset, I mean, pair programming has got to be at the top of my list for how to do that. It's just so beneficial.

Pitching pair programming to leadership

I wanted to ask, because in your talk, you talked about needing to pitch this to leadership. You were like, hey, leadership, you're going to have to let two of us work on one thing at the same time, which is going to feel like you're spending twice the resources for the same amount of time. What was the most persuasive thing or metric that you feel like you were able to use to persuade leadership?

Yeah. Kristen presented this slide in our talk. And I think we pulled out three key ones, which was that, yes, it is double, sort of double the resources, but that doesn't mean it's double the time. The statistic we reported was there was a group that did sort of a longer term study of the results of pair programming with developers. And what they found was that it does take 15% more time to implement a pair programming project, but that results in 15% less defects in the code. And so one thing we tried to highlight is like 15% less defects is not like equivalent to 15. They don't like balance each other out, like saving even like 5% of the defects is probably a lot more time than just 15% of the time spent in the project, right? Because you have all these downstream implications and other teams get involved and maybe you have production data out there and it's impacting something like that.

And so the question that I got was, I'm surprised that you only said 15%. I would have intuitively thought it would be 100% more time because there's two of you. Two people. Right. And so, but I do think that projects go quicker when you're paired because, so I guess maybe I should get into a couple of different kinds of pair programming. The most common one is called like driver navigator, where you're actually sitting together. And even that is going to be quicker because somebody is sort of like, it's like they have a roadmap and they're like, oh, the next thing we're going to need to do is this. And that's going to, we're probably going to have this little bit of a problem. Let me go see if I can resolve that or think through the next step while you're coding this previous thing. So it is quicker, I think, once you're in it.

But I think what people struggle with is that hurdle of getting into pair programming because it does take a little bit more time to get started because you're trying to learn each other, right? First of all, you have to get your repo set up and make sure you can all use Git and collaborate effectively. And then, you know, you've got everything named the way you want to. And sometimes you have these conversations about, well, how do you want this organized? Well, I was thinking this and I was thinking this and you have to compromise. And in the end, I think you get a better product, right? Because more than one person has looked at it. But it certainly can, it can slow you down.

Our leadership was not particularly concerned about the resources. Thankfully, we have a pretty young team. And so we had proven ourselves to be really valuable. And they were kind of like, hey, if you say this is the right way to go, let's give it a shot. But also, we had previously had a lot of conversations about how are we supposed to maintain this? And for how long do we maintain it for? Like forever? And so how many projects can we accept to maintain without becoming just a maintenance team? And so I think that argument was really pivotal for our leadership was that you don't, you're not stuck. It's not a real risk to deploy this thing. Because we had, so the particular project we talked about in our talk, Kristen and I both are familiar with it. But outside of that, we also have a standardized like team readme. And so we've put enough details in there that anybody on our team could pick it up and have some context to get going with it. So I think the stability that we were able to sell with pair programming was probably the biggest comfort for our leadership.

Challenges and benefits for individuals

Arsenis, would you like to hop in and ask that live? Sure. All right. Thanks, Libby. And thank you, Chris, for joining us today. So my question is, you know, kind of continuing with this pair programming. But as a when I'm writing code, a lot of times I think like I go into a zone and I'm just kind of doing things on my own. I don't want to hear anything from anybody. So I'm wondering in pair programming, is there any are there any challenges or additional benefits to the individual that you've noticed? Like for me, one of them would be kind of sharing the coding moment with like like kind of getting out of my own head when I'm when I'm writing code. That would be a challenge.

Yeah. Great question. I think I've definitely had moments where I've sort of been on a pair programming call and I like I can't like my brain's like not I'm not in it enough to like get to the solution. And then as soon as I get off the call, I'm like, oh, let me try this little idea. And I'm like, oh, yeah, now I know what to do. And so I think the other thing that that we tried to emphasize in our talk is pair programming is not there's not like one way to do it. And so you have to really know like your own strengths as a as a programmer and and your own weaknesses. Right. And so you may have to say, I'm blocked right here. I need to take a break. Let's do this separately. Think about the solution and come back and see what we what we had together. I think the biggest benefits is what Libby said earlier, like watching somebody code live, you can really you may end up at the same exact answer, but the way you literally the keys you typed to get there can be very different. And you can just learn some really cool tricks or like someone uses a totally different package than you.

But I do think that you do have to know when you need a break, but you have to also balance that with like you don't just need a break because it's uncomfortable, because sometimes you need to lean into that discomfort. And and that's where you're going to actually like like get to the sharp point, like you're going to iron each other, like you're going to sharpen each other because you're you're really challenging each other. Like, no, I really thought we should do it this way. Well, I really thought we should do it this way. And instead of just like separating and sort of like presenting like your own business case back to your partner, like you can you can iron it out together and you you have to be willing to be wrong or say, I see it that way. You seem really passionate about that. Let's try that. Let me let me set aside what I thought was best and try something else. And I've been I'd like to think I'm a fairly humble person, but I have been even more humbled in pair programming because there have been times that I in my head, I'm like, this is stupid. This is absolutely the wrong way. And then it works beautifully. And I'm like, well, I see that's why I'm better with someone else.

I've been I'd like to think I'm a fairly humble person, but I have been even more humbled in pair programming because there have been times that I in my head, I'm like, this is stupid. This is absolutely the wrong way. And then it works beautifully. And I'm like, well, I see that's why I'm better with someone else.

Yeah, you know what? I think that one of the benefits for me is that I don't stay struggling forever when I have a mistake because someone else is going to see it easier than I can. If they're navigating, they'll be like, oh, it's that extra space you have around that, you know, whatever that thing is, things that I just wouldn't see. So instead of me staying stuck for 15 minutes trying to figure something out, somebody else can unblock me super quickly.

Um, I do experience the same thing you do where I'm like, I'm I just can't figure this out right now. But I know the moment I get off of this call, I'm going to figure it out in two seconds. So let's take a five minute break and like meet back at the top of the hour. Fantastic question, Arsenis. And Arsenis is going to be our guest next week, everybody. Arsenis is a data scientist at Indeed. And he's going to be joining us to talk about his data science journey and all kinds of stuff that I love to talk about, like figuring out who you are as a data scientist.

Okay, I put another poll in Slido. I wanted to go over the results of the first one. The first one was, have you ever done pair programming at work? Chris, only 25% of people said yes. 75% of them said no, they'd never pair programmed at work. And then our new poll that we have up is, does having someone see or watch you code make you self-conscious? 85% of people said yes. And this is something that I really need to help learners get over a lot when they're first starting, but also seasoned programmers need to get over it. Do you have any tips for that?

I would say, find somebody at your work that you respect and that you know will respect you and try, see if you can pair program a little bit with them just to get the feel for it. Even if it's just a sort of a, maybe a pet project, right? Something that is not like business. Low stakes. Yes, that's what we mean. Yes. Something that you're not sweating, just to see, because sometimes you don't, you can hear us say like, oh, it's so cool. But when you feel that moment, that spark of like, you've been doing that the whole time. I could do that too. It's like, so it's that moment, if anybody's ever taught, it's that moment that you see your students get it, but it's happening inside of you. It's so cool. And so if you can find, I don't want you to just go out and go to the most intimidating person at your company and be like, let's go. That is not the way to build your confidence. So find a safe place, make sure that it's a safe place for you.

And to be honest, not everybody has, I mean, I've been at Nissan for six years and when I started, there was nobody here that I could pair program with. There wasn't even data science as a job title in my area. So you may have to build into it. And maybe you can be the person who is that safe person for someone else. Maybe someone else is interested in learning Python or R or something. And maybe you can just be like, hey, yeah, you could probably do that in Excel. Do you want to do it with me? And we'll do it in R instead. And just a little project. It doesn't have to take forever.

Supply chain data science at Nissan

That's a fantastic idea. And I wanted to also sort of get a little bit more context around supply chain stuff. Could you give just a super high level overview of like, what does that mean? I work at Nissan. I'm a data scientist and I'm in this sort of supply chain area. Yeah. So if you think, I'll try to paint you a picture of like, think about a process flow here, right? So we have purchasers in our purchasing department and they go and they figure out who they're going to go buy parts from, car parts, right? Wheels, steering wheels, whatever, electrical cords. And so that's purchasing. That is not supply chain yet. Once we have contracts with these suppliers, then we order parts from them, right? And so now we're starting to get into supply chain. So we bring parts from suppliers to the assembly plants. I'm at one of them right now. So that's supply chain. Then the parts are here on our campus and they could be in a couple different locations. Then they eventually go to the manufacturing line and they get put on a vehicle. That is now manufacturing. That is not supply chain either. So supply chain is on the front end, bringing parts in. And then after the car is built, there's another supply chain, same supply chain, but another component of supply chain is where we have the finished vehicle and we need to get it out to a dealer. So supply chain is sort of, it's like we're giving a big hug to manufacturing. We're on the front end of manufacturing, bringing raw parts in, and then we build cars and then we're on the back end where we deliver the finished vehicle.

So we have a lot of data. We have a lot of part level data and then we have a lot of like vehicle VIN level data, but it's all sort of before it goes into be a customer. It hasn't been bought by a customer generally. So there's not a lot of PII in our data. We don't have customer information because it's all pretty much before it's been to the dealer.

Pairing across experience levels

Thank you. I got a question in Slido that is anonymous. It says in pair programming, is it better to have both devs be at the same level of experience or expertise? And like, how does that play out when they're not the same level? And there are a couple of replies to this, which I think are really interesting. One is like, what if the second party is not a dev? Is it, could it just be like a tech savvy stakeholder? And the other one is, hey, it's a tough thing to judge or measure skill and comfort with programming just casually. Like it could cause discomfort or awkwardness if someone thought that they were the more experienced coder and it turns out they're not. Do you have any thoughts on those?

Yeah. And I definitely don't think we should be going around labeling people. You're a good dev and you're, you're a not good dev and we should pair you together for that reason. That, yeah, nobody wants to be judged by their... That's probably not beneficial, right? And I, so I think the question was something along the lines of like, is it best to like pair people of sort of equal maturity? And I think all the pairings are great. I think you can get things out of all of them, but you probably do want to be intentional with like, when do you choose more equal maturity pairings? And when do you choose a more like upscaling opportunity, right? And so when, so Kristen and I are both data scientists, we both have the same master's degree in data science from the same university. We both were on the same innovation team. So I would say we are, we are maturity wise, we're equal. And so we can do projects a certain way.

But I also do a lot of projects where we're like an innovation team in supply chain, but we have other, we have like an inventory control team and we have like a finished vehicles team. And so we have like techie people. Maybe they're not quite like a data scientist, but maybe they can program, right? Like they can program in Python and we want to implement a solution for their business area. My team, my innovation team should not own that solution. That business team in that particular area ideally should own that solution because they know when it's going to need updates. And if they can make that update, my team is off the hook, right? We can go do innovative things. And so we've done a lot, I've done a lot of pair programming projects with other business units. Like this would be that like key stakeholder kind of idea where I, and I like physically the first few times I had to do it, I had to stop my, I like committed to myself before the meeting that I would not share my screen. And it was hard because I'm like, click, yeah, click over there. No, the other, no, the other one, no down a little bit. Right. And it's, it's, it's tough, but if you don't go through that discomfort, you never let that other person upscale. Right. And so, you know, I, as I would say, as the lead in that pairing, I tried to be really patient and really have a lot of empathy and just be like, no, you're doing great. A lot of encouragement and like, look at how far you've come, right. Help them reflect because sometimes when you're in the learning, it's hard to see that you're learning, but if someone will help you like look back, you're like, oh, actually, yeah, that's pretty cool. So I don't agree. Yeah. I don't think there's a bad way to pair.

I think it's important to also remember and recognize that just like with mentoring, you're going to learn by directionally in pair programming. So if you are the more experienced programmer, you are probably going to learn things from the less experienced programmer and being open to that and expecting that and embracing that is going to be mutually beneficial for everybody. I learn things from learners constantly. They're Googling things that I take for granted, right? So they're finding new and different solutions that I don't know exist. It's one of my very favorite things. It's like reverse mentoring. Everybody wins.

Container fill ratio: a supply chain ML project

Rachel had a question about supply chain too. Rachel, did you want to ask that while I'm looking for the question? Yeah, sure. And thanks, Chris, for explaining some of the supply chain use cases. I always just think it's so fun to get to hear what are the different problems that people are solving across industries. And I remember you telling me about the container fill ratio and that being something that really opened my eyes to some of the problem solved in supply chain. I was just wondering if you could tell us a little bit about that.

Sure. Yeah. We mentioned this. We kind of allude to it in our talk. We sort of give that as the example of like, look, we actually did pair programming in the wild. This is not something we just have thought about or thought it was fun to talk about. So we bring in these parts from overseas. Some of our parts come from overseas. Most of them don't, but some of them do. And I don't know if you've ever seen these pictures of these massive containers that have all these shipping containers, like these boats that have these big shipping containers on them. So those big, they're literally tractor trailer size, right? The trailers of that, but for shipping, so they're more sturdy. And so we fill those up with parts, but we can't actually fill up the whole container, right? Because there's like air in between these parts. And so we have a KPI that's called container fill ratio. And it's literally just like how much space does the actual material take up divided by the total, like actual cubic meters of the whole cube. It's not really a cube, it's a prism.

And so that's a KPI that we use. And so we needed to predict, we were asked from the business to predict what would that container fill ratio be if we know roughly the demand, right? What do we expect that container fill ratio to be? And that was important for helping our team book containers. They have to like reserve them in advance, the capacity for them. And so they sometimes get these sort of wildly off bookings and it either costs us money because we have to like, oh no, hurry, we need to scramble and we need a couple more. Or it's like we've reserved seven and we only needed three and we just paid for space. So that was one, we did a machine learning model to predict that. So again, it's a very specific use case, right? Only a couple of people need access to it. So we were able to build it with Posit tools. We used Vetiver, we used Tidy models, we used Vetiver, and then we published it on our Posit Connect server. And so our business users could just go to Connect and they could like go and see the things real quick and they could get their answer in like five seconds. What is the prediction? And then they could make whatever decision they needed to make. Nice, which is like the ultimate goal, right? And having, deploying something that other people actually use is like the best feeling ever because so much of what we do as data scientists goes nowhere. It's like a POC that goes nowhere.

AI and pair programming

Do you think that AI and specifically things like co-pilot might be able to replace some aspects of peer programming?

I'm, I'm hesitant to say to just like flat out say no, because, um, I've, you know, I, I believe that I have room to learn. Um, so I'm sure that probably there are some, maybe, maybe just offering different coding options. Um, but I do not think that it is, uh, an equivalent replacement for another, another human who, as we've just talked about, right. Has different personality traits and like can talk to stakeholders. Like your AI cannot talk to your stakeholders. Uh, or maybe I would not recommend you have your AI talk to your stakeholders about your project. Um, but yeah, certainly I think, I think like co-pilot can help you with like code suggestions. And I would argue, like do that in your pairing. I wouldn't say like, you have to do them. They're not even like separate things, right? Like I would, I would do both, but I still think having two people, two different, uh, like thought processes about how to like, what's your next step in the project. Cause generally when we talk to AI about coding stuff, it's, it's like a specific thing that we're asking it to do, but like the project is probably a bunch of specific things layered together. Um, and I think, I think to have the redundancy, you certainly don't get any redundancy.

And like I kept wanting to go like, just tell everybody like how great pair programming is because like, you can just like relax. Like it's not all on you. And in fact, none of it's on you. Like you have, you have officially like documented it and like created that redundancy. So like, you are not the only person who can do things. Um, and you certainly don't get that with AI, unfortunately.

Yeah. I agree. Cause it is still on you. You are still the only responsible party when you're using AI. AI is not going to take on any of the responsibility. And when I use AI to help my code, I actually know less about it. And so if someone's like, oh, like now can you change it to do this? I'm like, oh, I don't know. Let me ask the AI if it can do that. Because I don't always know every single thing that was coded. And I think that's, I'm pretty cautious in that regard. I'm pretty hesitant to like put that in my production tools because if I don't know what it's doing and I can't explain that to my stakeholders, that comes back. I look like an idiot. Right. Rightfully so.

Career advice and working out loud

Yeah. Yeah. We have a lot of interns that come through our supply chain area. And so I actually get this question a lot from them because they sort of see my role as data scientist, and maybe that's what they are interested in doing. And the advice that I typically give them is try not to just go too deep into the newest thing right now, which if we're being honest, is just AI. That's it. That's the only topic. And try to spread yourself out. Be able to play any position on the team, which means you need to understand math, like really understand the math that's happening. So that when someone says like, oh, this model seems to be under predicting all the time. What do you think about that? You have something that you can say about that because you've looked at the data and you understand why is there a bias in that model and what models might not have a bias in that same way.

So understanding math. I know a lot of people just sort of equate data science to machine learning and AI, and that boils my skin because there's so much more to good data science than just that. So I have a degree in math. I really love operations research and mathematical optimization. So that's not a thing. That's not for everybody, but that's a data science skill set that if you want to be able to offer a lot of different solutions, that's an area you can focus on learning. Also like learning how to communicate with people and like tell a story. Like how to build proper visualizations. Like these may not seem as like cool or like they're not like home runs because you know they're not like the hottest thing right now. But they are like fundamental and foundational and that's the stuff that people learn to trust you with. If they can trust you with like a visualization, then maybe they can trust you with this black box machine learning model.

Data science meets refereeing

Chris, I wanted to ask a quick rapid-fire fun one because Nellie asked, have you ever done any fun data stuff related to your refereeing? I want to know too. I have, I have. I'm excited about this. Yes, so college soccer in the United States and there's basically two organizations that assign referees to college soccer games. Okay, one is called elite college soccer referees and the other one is called the National Intercollegiate Soccer Officials Association. The NYSOA group is the longer standing one. They're the bigger one and they collect data about their officials through when we like register with the NCAA. We have to like register on this platform and they, so they get this, they get some like demographic data and some, some things like that. So I, well, I got connected with the executive director of NYSOA and she actually refereed the women's world cup final in 2023, 24. I don't remember what year it was. I'm really sorry. But yeah, Tori Penso, she's amazing. And so she's the executive director of NYSOA and she, I know her personally. And so she like, was like, oh, you're a data scientist. Can you do something with this data? Like, I want to know things. And I was like, yes, yes I can.

So I took, they, they took out the PII. Like I had like age, I had ethnicity, I had race, I had years officiating, I had like their location, which was important because she wanted to see like how far away or like the national assessors from like the national referee. So yeah, I took all that data and I, they were basically like, just, just go like, see what you find and present back to us. So I did this. I actually worked with, I did, I did that in pair programming too. I didn't even know it. There was an intern who was working at UT, University of Texas, San Antonio, I think, who I got connected with. And she was like, hey, I have this person. She needs to do a data, something internship or like project. Can you, can you guys do this together? And I was like, absolutely. Let's, let's do it. So like I worked with her and like, we cleaned the data a little bit. We put it into Tableau and we did some analysis. It was pretty much just building a bunch of visualizations, but then she and I presented that to the executive board at their like annual meeting or whatever. And they were, I, I continued to meet people from the executive board and they're like, oh, you, you did, that was amazing. Like, cause it was the first time they had ever looked at their data. Can you believe it? In like 2023, it was the first time they had ever looked at their data and they could see, oh, 7% of our officials are women and more than 50% of the games we assign are women's soccer games. And that's a problem. We should be aware of the differences, right? Like, like how are we going to make goals for ourselves if we don't know where we're at? So that was super fun to do. Totally just did it on the side. But yeah, loved it.

What a super fun question, Nellie. Thank you for asking that. And this is a really good example of like something I've been talking to a lot of people about lately is giving talks, doing things on the side. Presentations are really stressful and time-consuming sometimes, even just like giving a PositConf talk. It takes a lot of your time and your effort. And so what are the benefits of that? What do you see from that? It's that exposure to people seeing you do this work. Other people are probably doing it and not talking about it. If you do it and you talk about it, you put yourself out there in a really great way and make all kinds of fantastic connections. And you don't even have to be the best or the brightest or the most talented at something. If you're the one talking about it out loud and brave enough to do that, you're the one who gets the opportunities. So really, really working out loud is so beneficial and I encourage everybody to do what Chris did.

And you don't even have to be the best or the brightest or the most talented at something. If you're the one talking about it out loud and brave enough to do that, you're the one who gets the opportunities.

Balancing pair programming with urgent tasks

Adam, you had asked a question. Adam T., if you are here, you could ask that live real quick. Hi, everybody. Hi, Chris. Hey, Adam. Basically, hello. I was basically wondering how you balance the time that gets added on with pair programming with tasks that need to be done quickly because I completely support upskilling. You know, if you've got a less experienced programmer with you or if I happen to get somebody who's more experienced, which is a wonderful thing for me, but it kind of adds on to their time load and I don't really want to hold them back or anybody else in the workflow. So do you have a system of organizing tasks so that you don't accidentally put something to a pair and then say, great, you all get to learn from this at the expense of holding somebody else up?

Yeah. No, our system is really just a vibe system right now. It's really just checking in and trusting people to do their jobs and know their boundaries. And so, yeah, I mean, I think there are certainly times when we get a request and I'm like, oh, I really should include these other people on fixing this, but they need this done now. I'm going to fix it and then later I'm going to go back and when they have time, I'm going to go back and I'm going to show them what I did and maybe have them rerun it and check it out. So we actually, there's a name for this and we lean into this in our talk as well. This is called refactoring, which is, we didn't know, I'm going to define it because we didn't know what it was when we were researching for our talk, but it's the process of going back and reviewing your code and making it more accessible and readable and maybe adding those comments and stuff. And so one of the other approaches to pair programming is not sitting together side by side. It's actually what we call in our presentation as unstructured asynchronous, where you're actually separating from each other and maybe you're doing different components of the project individually, but you will come back together to refactor. And as long as you're refactoring together, we believe if you're like, like Chris and I are sort of on the same level of like maturity, I don't need to watch her type everything, but I can go back and look at her code and I can say, oh, I see what you did here. Did you think about doing this here? Or that's unclear to me. Can we add a comment? Because I wasn't sure what that code was doing. And then you still get that redundancy with less of that time burden. So I think the big takeaway is like pair programming can look like anything you want it to look like, as long as at the end of the day, my analogy in our talk is that everybody should be able to ride the bike.

Right. Yeah. I love that. And for anybody who doesn't have the context of Chris and Kristen's talk, they do go over the different types of pair programming and different projects or different tasks might warrant a different level of pair programming up to and including asynchronous so that you are just like passing things back and forth over a net and refactoring after each other or checking things, which I think is great.

This was a fantastic Data Science Hangout. Chris and Kristen both, thank you so much for being here. This is one of my favorite topics. I would love to continue this conversation in the Posit server, so hop in there so we can chat about it. Thank you so much, Chris. Would you like to say goodbye to everybody? Yeah, this was so fun. I really I love this group. I love the energy. I love the positivity. I appreciate all of you for your contributions and just thanks for making it so fun.

Wonderful. Thank you all for being here. If you would like to catch Chris's talk, it is still being edited and will be up on demand on our platform quite soon, I hope, and then all the talks will be up sometime in December. We need time to edit them all and fix the captions and everything up on our YouTube channel, so you can look forward to that. If you saw good things in the chat today that you want to save, you can click the three dots at the top right of the chat to save it. I'm seeing lots of clapping and thank yous. If you're not looking at the chat, Chris, the thank yous are rolling in in waves. I think everybody had a really good time today. Thank you, Kristen, as well, for joining us and helping add context and stuff. Everybody, as a reminder, we'll see you next week with Arsenis, a data scientist from Indeed. We love seeing you. Say hi to me on LinkedIn. In the meantime, if you send me a connection request, please put a note on it saying you're from the Hangout and I will see you on the Discord server. Bye-bye, everybody. See you next week.