In today’s episode of The Rabbit Hole, Dave Anderson and Sophie Creutz attempt to answer the question: when should you pair program and what should you pair on? We apply the basic principles of pair programming to a non-programming task like reading documentation, using an article about learning organizations as an example. Hate pair programming? Well, we also touch on how you can reframe it as deep collaboration and view it as a skill that you can work on. Stay tuned for practical advice and helpful resources, plus so much more!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 228. When to Pair Program
[INTRODUCTION]
[0:00:01.9] DA: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. I’m your host, Dave Anderson. With me today, we have the co-host/guest extraordinaire/superhero.
[0:00:15.4] SC: Sophie Creutz.
[0:00:16.8] DA: Yeah, I think you’re just bagging all those titles, slowly moving up the ranks.
[0:00:19.3] SC: Thanks for the introduction, that’s a great one.
[0:00:23.2] DA: Yeah, so today on the podcast, we are going to try to answer the question, when should you pair a program and what should you pair on?
[0:00:33.6] SC: Yeah. Dave, have you ever tried to pair on something other than programming?
[0:00:40.7] DA: Yeah, I think we just did it, because we were pairing on an outline, we were writing a document in a collaborative exercise a little bit.
[0:00:49.8] SC: Right, we were creating it together in real time.
[0:00:53.3] DA: Yeah, the seed that kind of shared this or started this conversation was a story that you had that I thought was really interesting.
[0:01:03.2] SC: Yes, I decided that I wanted to try and call Australia and I figured that maybe it was something that I could pair on with another smart, capable individual. You can always rubber duck of course, we might be familiar with the concept of rubber ducking. It’s when you talk out-loud to an inanimate object as if it is a person. Often, this inanimate object is a rubber duck. Oh, goodness, Dave is showing me an amazing rubber duck right now.
[0:01:35.9] DA: It’s green and – it’s green and it has a purple mohawk. It’s kind of wild
[0:01:42.3] SC: Yeah, put that in your minds eye, dear listener, if you ever need to rubber duck.
[0:01:46.3] DA: It’s the duck with all the answers. At least some attitude.
[0:01:49.2] SC: Isn’t that great? Yeah.
[0:01:50.6] DA: If it doesn’t have the answer.
[0:01:52.0] SC: Yeah, not to go down a rabbit hole here but it’s almost as if you can draw a parallel to something like the flying spaghetti monster in the sky.
[0:02:03.4] DA: I guess so, yeah. I think that’s interesting. It’s like, you have this problem, no amount of code will solve this for you. I guess you could look up a library and you could probably use Toolio or something and call Australia.
[0:02:17.1] SC: Right. Isn’t that the senior developer go-to; is there a library or a package that I can use for this to solve this problem?
[0:02:23.8] DA: I’m just going to MPM install this and create this in the size with no regard.
[0:02:30.7] SC: Fantastic. Calling Australia, I lived with a fellow Strider programmer and we worked on doing that together and we asked each other questions such as, “What’s the exit code? Do we need an exit code? What about a country code? What about do we need to actually type in that plus sign in order to call this number from a cellphone all the way across the world?” It turns out, the answer is yes, but through the process of talking about this with another individual, we were able to surface some of these questions and get closer to an answer.
[0:03:05.0] DA: Yeah, that’s true. I guess kind of also feeling maybe a little less stuck than you might be just staring at your phone or looking at an article online and being like, “Okay, am I ready to try this? Am I going to incur the wrath of my telephone company or whatever?”
[0:03:22.9] SC: Exactly.
[0:03:25.2] DA: Yeah, I think another thing that happens a lot when we’re in the process of doing pair programming as well is reading documentation. That can be a challenging thing to pair on because everyone reads at a different pace and people have different styles of reading. I’m kind of a non-deterministic reader of technical documents. I scan a lot, I bounce up and down, I read the beginning and then the ending and then the middle. I don’t know, my brain doesn’t work like that but there are ways to apply the basic principles of pair programming to even something as unstructured as that.
[0:04:07.5] SC: Right, yeah. Well, I think it probably is all about the structure that we do indeed apply to what we’re trying to look at together. We’ve applied a structure to programming together. Can we apply a structure to reading documentation together? For instance, if I was looking at this Wikipedia article about what is a learning organization?
You say, Dave, that you might sort of read this in a non-deterministic kind of way; look at the beginning, look at the end, look at the middle, and then maybe someone else’s style would be to read every sentence very carefully, or to look at it and then articulate out loud what they’ve gotten from an initial scan. I might say something like, “Let’s figure out what a learning organization is. It seems like according to this article, it’s a company that facilitates the learning of its members and continuously transforms itself. Ooh, that’s super interesting. What do you think about that, Dave?”
[0:05:09.3] DA: I think that that would be a different style, different conversational style, I guess, to picking it apart.
[0:05:16.1] SC: Yeah, that would be more conversational, that’s true.
[0:05:19.2] DA: I feel like the fundamentals of pair programming that we can pull out and apply to a different situation is looking at pair programming as a way to get really fast feedback, setting up quick feedback loops, and information exchange between individuals.
The way I might structure a documentation reading session or information exchange session would be, we can set out, pair it together on what our objective is, what is the key question that we’re trying to answer, and then break apart, dig into the information together, but silently, and then bring it back together and have that conversation and information exchange and set it up as a feedback loop where we can keep on asking, “Do we need to go deeper? Do we need to look at different resources? Should we break out and scatter and gather resources and then bring them together and then dig into them together?”
[0:06:24.1] SC: Nice, yeah. Then, perhaps when looking at this article, we could have the guiding question of, “How does an organization become a learning organization?” Then we might start looking at the article. You or I might say something like, “Oh, it looks like there’s a section a little bit further down on this article here called development and if you read that section, you’ll probably get some information that answers that question. Also, if you read a little further, there’s also a section about barriers to an organization becoming a learning organization. Maybe we can dig in a little deeper there.”
[0:06:58.4] DA: Yeah, I might – I mean, if we’re looking at this particularly, I might ask like, how do you bring it down into a smaller things? Okay, the organization is one thing but if we look at the team or an individual, how did those same principles scale at different levels? I think there’s a lot of different angles that you can go at and then kind of bounce off each other and have more creative thinking because you have a second brain that you're bouncing off of.
[0:07:30.8] SC: Yeah, it’s sort of the “yes and” that occurs when you’re bouncing the idea off of someone else, which if you're not familiar with “yes and,” it’s a technique originally taken from comedic improvisation where you say yes to everything that happens and then build on top of it.
[0:07:52.3] DA: Yeah, it can get pretty absurd but the programming is grounded in reality, I guess, a little more.
[0:08:02.1] SC: Yes, of course, but I do think that the way that that can apply is in thinking about ways in a very positive way and structuring things from a growth mindset. All right, we dove in there a little bit to pair programming documentation together and this sort of begs the question of, what if you really hate pairing on things? I know there are folks out there who, it’s just not their style.
In fact, I have a quote here from an article about how it might not be quite the right thing and the quote is, “If the anger annoyed, depressed, stressed or otherwise, deplete the engagements of developers who don’t handle them well, surely, that’s a net negative, not a win.” So yeah, this is referring to pair programming as causing these things.
[0:08:53.1] DA: Right. You think those are all kind of emotional things where it’s like, “I am feeling restricted. I’m feeling held back and frustrated by this experience.”
[0:09:04.2] SC: Yeah, frustrated, maybe not feeling heard, maybe not exactly sure how to participate. My devil’s advocate response to this might be, “Well, maybe it’s not so much that you don’t like pair programming, it’s that you might want to examine how you're doing the pair programming.”
[0:09:23.4] DA: I think that there’s also kind of a challenge of, first of all, you do have to have a conversation about how often you actually want to do pair programming or how often you want to have that kind of deep collaboration, which kind of, I guess, it could be a reframing of it. How often do you want to collaborate really intensely with people on problems? Because it doesn’t have to just be programming or coding. It can be any of the things that we’ve been talking about. Yeah, it’s good to have some Slack time on the team so that you can have that kind of independent exploration and recharge and introvert time and deep thinking.
[0:10:05.2] SC: Yeah, absolutely. You know, put your headphones on, get in the flow state with something.
[0:10:10.4] DA: I think another thing too is that pair programming or that kind of collaboration is something that is a new skill. It’s a different skill and it’s possible that you might have some growth to do in that area. You might start out and not be meshing and not be feeling like you’re getting a lot done. Like many skills, the more you work it, the more you have those conversations and feedback about how things are going, and how you can change the way that you're exchanging the information, and the way that you’re setting up those feedback loops.
[0:10:48.7] SC: Practice makes perfect after all. I hear that’s what they say.
[0:10:52.3] DA: Yeah. It’s frustrating because you’re like, “Wait, I already practiced being a developer or doing this task and I got really good at it and now this feels like I’m bad at it and this is frustrating.”
[0:11:09.1] SC: Yeah and we certainly have talked a lot here too on the podcast about what pair programming is and what it looks like. These navigator and driver roles and how to make that work. Definitely dig into those resources a little bit as well, but yeah, I think just diving into resources about pair programming and then maybe establishing with the folks that you are trying to pair program with what your knowledge is on these things so you’re creating a shared understanding.
[0:11:38.9] DA: Yeah, this is definitely a topic that we talked a lot about, from episode number four on pair programming, 141, a deeper dive into it, 127, remote pair programming. It’s something that we’re definitely passionate about and feel it is a very useful tool to have in your toolkit, no matter what kind of problem you're trying to solve.
[0:12:02.6] SC: Right and with that in mind, I might add that the pair programming experience with your team, with your colleagues as it is right now, is an evolving process. It’s like a living document so to speak. You will practice it, you will learn it and it will involve into the best possible style for you and your team members as you keep practicing it.
[0:12:24.3] DA: Totally, so yeah, keep at it and hopefully it will help you feel more connected with folks on your team.
[0:12:31.0] SC: If you’re so inclined, feel free to pair on subscribing to this podcast.
[0:12:38.4] DA: Right, yeah. Just get someone to screen share, and then take control of their mouse, see one of us will pair with you, we’ll take control of mouse and then you can – you should click that button.
[0:12:47.8] SC: You could even listen to it together as a team. Imagine that?
[0:12:53.1] DA: Wow. Yeah, why not?
[END OF INTERVIEW]
[0:20:49.7] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode; subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Episode 141: Pair Programming Advanced
