Pair programming is preventing me from being the developer I want to be

Transcript is auto-generated and may contain errors.

All right, folks. We are going to a question submission from the codecommute.com website, which proves that the question submission actually works. So, that's good news. Um, this one is about pair programming. Um, and I think it's a good one. I think this is interesting to talk through. So, this person says they're that they were fresh out of college and they were okay with pair programming at the time because they're surrounded by experienced engineers. They learn a lot from it. Um, which is great. I think you know it's one of the really awesome things about pair programming. It's not the only thing but it's really good. And they said they absorbed tons of knowledge and they said now that they're a couple years in and they feel fully competent on their own they feel that pairing is actually more of a constraint. So they said our team under operates under strict pairing dynamics pair bromine dynamics all code written with two sets of eyes so that we push straight to main without diff reviews.

Okay. So different review process or no review process because of that. They said older folks on my team have more priorities both at and outside of work but I have to operate at their pace due to pairing rules. And then they say this I have the opposite of burnout. I want to do more. Any experience in a situation like this where I just wish I was allowed to ship more code? Um this is challenging. I think it's a really good question. This is the kind of thing that on the surface I look at this and I go, this is why I don't like what sounds like dogma. And what I mean by that is that when they say I'm just scanning my my computer screen here, like my team operates under strict pair programming dynamics. What the hell is the point of things being so strict if there's going to be people that can't operate effectively?

I don't I don't like this kind of thing. I think it's super cool. If you want to encourage pair programming, awesome. I think there's a lot of really great things that can come from that. They even call out from their own experience, there's a lot of great things that can come from that. So, I like that idea a lot. But as soon as you get into like strict anything, it's And that's because that if you start making rules for how to operate, you're putting process over people. And in this case, the whole idea is that you want it to be people centric. That's why you're doing pair programming is to take advantage of the people aspect. But then you layer on process. You force it and then it's going to detract from that. So like simply put, I would say like for me it would be either like find a way to bring this up and talk about it not being a strict thing.

And this goes I've made videos on this before like how much do you want to push on that culture to shift it? If you you love where you're working, you love your team and you're like feel passionately about like this isn't a thing that makes sense to be dogmatic about. We should try to evolve what this looks like where the core of everything you're doing is like primarily like you know pair programming should be you know the the way that you approach things. But then there's these other scenarios like I would encourage you to go like have those conversations, try to promote that, get buy in for it and see if you can make the team culture change and rally behind that.

However, I realized because I have also been in situations where I'm like even when I was really passionate and wanted to change things and was speaking up for things and there was no buy in I'm like okay well either I ad like adapt to this circumstance or I leave and I have had to leave and it sucks but at the same time if you're in an environment that's not going to be conducive for you to be you know for your effectiveness your ability to grow in your career, your ability to actually ship software and value effectively. It's it's not a good team and not a good team for you. And that doesn't mean it's because you suck and it doesn't mean that's because the team sucks. It's not a good fit for you. There could be other people on the team. I'm just let's let's make this up, right?

I don't know the person that submitted this. I can see their name. I don't know them. They could be in a situation where they're the only person on the team that isn't, you know, effectively able to work like this. Every single other person on the team is a absolute machine when they operate and they pay a program this way. That's awesome. And if this person is not able to kind of fit into that, it doesn't mean it's because they're terrible or they're not skilled. That's just maybe not the best way for them to work on everything. So maybe legitimately maybe it does not make sense for the whole team to change. But if you don't have the conversation to bring it up and try changing it, you won't really know. Now it could be the opposite of what I just said, right? Maybe it's a small majority of the people on the team that really benefit from that and everyone else is kind of just like doing it.

This person was saying, you know, like there's older folks on the team, they have different priorities. Maybe maybe like statistically that it's lined up quite well because if you have more people that have a similar type of I don't know like priority in terms of uh time and things that they can focus on in and out of work. They might just line up really well and they're like cool we got so far today like you got to run errands I have to pick up kids or whatever like cool like we you know we got done what we said time to go and do other stuff. Maybe that worked for a while. Maybe that worked for a really long time and the team has grown and changed and whatever else. Maybe that doesn't work so effectively anymore. So I there's a lot of things when I approach team dynamics that I have ideas about that I'm like I think this is an effective way to work.

But the problem is that if you have anything that's like cemented, you start saying rules, you start saying strict. The only thing that I want to be strict on a team is that we have a strict focus on continuous improvement. The only thing that's strict is that we will have to grow and adapt and change. That's the only thing. That's it. And that's because there are things that I think are effective. There are things that I have seen work really well. And if we try them as a team and they are not working with the current team members or the current project or the current landscape in terms of the other business priorities, we might not be able to do that. I might there's people I've worked with 10 years ago and maybe if we worked amazing together in some circumstances and we tried working together again today.

It simply would not work the same way. And then it would feel like, man, this really sucks. It used to be so great to work with these people. This is how we used to do it. Like why is this whole process so crappy? And it's because it no longer fits. I think it's absolutely critical that you go through this reflection process whether or not you do agile or anything else something like a retrospective retrospective I said that right um this is what happens when you make videos like this and you don't edit them uh you have to do that kind of thing you have to be able to reflect you have to be able to say this is working really well this isn't this is so so and try an experiment try a change and keep trying things out in this particular circumstance. I don't know how much this individual wants to push on change.

Personally, I don't I don't know at all. If they're very passionate about it, I would try proposing it. I would try asking around and seeing like how do other people feel about this? Is this something where you start to notice other people feel similar? Can you talk to your your team lead, your manager, and try to see like can we try a different thing? In my opinion, if you're work, this is again totally my opinion. It's not professional advice. No one's paying for this kind of thing. I would say if you go the route of trying to drive change because you are interested in seeing if the whole team can become better from this, if it's something that either gets shut down, so if you're like your manager is like absolutely not, we don't do that. I don't know if they're not receptive to change, like personally, I wouldn't be down with that.

I would be like, okay. Like I know this isn't effective for me. I don't the pay would have to be so amazing that the other parts of my life I'm like they're all great. I don't have to worry about this, but I know how much time I spend at work. And I know that that would have to be a ton of money for me to not care. And I just don't think it would be realistic for me. I think that I would not be happy at work. And that's too much of my life to be spent not being happy. or and when I say not happy, if I feel like I'm not being productive or effective, I will not be happy. I would have to leave. I always want to find myself working within a team, right? Like even though I manage teams within a greater team where it's encouraged that we can promote change, we can, you know, we can challenge what we're doing.

We can have new ideas suggested and try things out. The team I work on right now, my manager has done an excellent job of that. There are people, there's processes the team has had in place and changed over time. We're trying new things right now. And it's great because it's enough of the team going, I think we should change this. And we all go, great. We might not have the perfect plan, but we know we want to try to change. Let's try. Let's start taking some steps. If we find they suck, no worries. Cool. We tried it. Let's try something else. and see what fits, right? If I'm not working in an environment like that, it's not going to work for me. I will not be happy. I will not be successful. And it's time for me to find something else. If I were in this person's shoes, I would try to promote change, try to see how much buyin there is.

And if there is not, that would be it. like unfortunately right now you know financial situations having something else lined up all that these are of course other factors I'm not just telling this person try and if it doesn't work like you know resign immediately but I think it gives you a more clear picture if you're trying to drive change and there's no support for it you're going to be stuck and I don't think that anyone should remain stuck I think the next thing is like well what do I have to do to get to you to get myself into a position where I'm going to be happy and feel productive, which is a whole different conversation, but um that's kind of what I would recommend in this case. I I think there is a tremendous amount of value to pair programming, especially when you have situations where um there's a lot of information to to share, a lot of knowledge to share with more junior people or just new team members.

It could be, you know, if you're working on a team, you could even have experienced team members, but someone's new to a particular area. Um, there's stuff I work on outside of work where we're building things together and we've been building things for years and we're like, "Hey, this is a pretty complicated thing." And it's not like we're getting more stupid over the years or something. It's like we're still growing. We're still learning. We're still doing these things and we've worked together, but we should still pair on this because there's some value to having different perspectives being brought in. Like you will see things that I won't see. You will, you know, walk through challenges and problems and do problem solving in a way that I might not do effectively on my own. We can use AI for a bunch of this now, too. if you're comfortable chatting with AI.

Uh I'm trying more and more to use a microphone to actually speak my thoughts to AI so that I can get some like pair designing and stuff even when I'm working alone. So I think there's a ton of value in doing it. So as you're listening to what I'm saying, I'm not like, "Oh, screw pair programming. This is such a dumb idea." The only dumb thing that I think here is like having strict anything. If you have strict process in place, you will have people that cannot operate effectively and if there's no, you know, room for for changing and evolving that, then I I think I think that's kind of dumb personally like I just think it is. So, um I don't know. I I think in like I said that would be my recommendation is to try and drive some some change. You can survey people around you.

Um, and uh, if you already know, like from working with your manager, working with your team, if you're like, "Hey, everyone's a resistant to any kind of change. I've tried this kind of thing before, or maybe you're of the mindset where you're like, I don't I don't have enough personal energy to put into something like this to go drive change." Like, you already have your answer, unfortunately. But you have it. So, um, super interesting though. I, you know, we talk about burnout and stuff on this channel a lot and uh it's I I just thought it was really interesting to hear someone say like I have the opposite of burnout. I think what's fascinating is that I bet you if this goes on for a long period of time, this person will experience burnout. And it's not because they're doing too much. It's because when they have to do stuff, they're like, "My hands are tied.

I feel like I have to work a certain way and I am burnt out from living in a and working in like a shitty environment that I can't be effective. I think they will absolutely burn out from it. It's just that it's not looking the same where they're burnt out from like, you know, you have to go do like 10 times as much work in half the time kind of situation. But um yeah, I the other thing that I might recommend too is that if you're surveying, you're going to go see if you can propose change is like the key part there is what is the change you want to propose? I don't know what this person wants to propose. So I would maybe walk through a couple of different mental models for what you can envision the team looking and operating like. Um, but this is sort of like a next level kind of thing that I would recommend is um, this might sound kind of weird.

I just want to kind of walk through this. I think a team that doesn't speak up and share any information or any complain about anything like not a great spot to be in. Um, I would much rather have people complaining about something than being like I don't I don't care enough to speak up or I am afraid to speak up. Those are a bad spot to be in. not a great culture. Lots of things that can change and influence that. But the next part is like, okay, well that now people are complaining. I do actually prefer that to people not saying anything at all. But what I like even more is that if someone's going to complain and say, hey, this sucks or this isn't effective or this isn't working anymore. Here's something else we could try. Here's something else I'm thinking about. I think that is the next level.

So, I really encourage someone in this position to give it some thought. If the team is willing to change, imagine if you're like, "Cool, I have three other ideas that we could look at." Open to more, of course, you know, because it's a whole it's a team dynamic, but here's three things I was thinking of that we could that we could go look at. And if you have ideas or you have ideas, let's chat through them. But at least I can propose something so that people aren't like, "Cool, I hear you whining about this, but like it's okayish enough for us, right? Like, how do you get them bought in?" If you have people that are on the fence about it, they're like, "Sure, like I've been, you know, I'm one of the guys pair programming and like it's working okay for me. I just don't care enough to go, you know, I don't want to complain cuz whatever.

It's fine. How do you get them bought into it, right? Oh, you know what? Like here's if we were to work this way and you have these circumstances, maybe that gives you some other flexibility or maybe this helps you, I don't know, like be more effective in this area of the code. Just making up, but the idea is like come with some proposals. And I think that really helps in terms of getting more buy in. So overall, love this question. I hope that's a helpful way to kind of look at things. Um, and yeah, I think that there's absolutely pros and cons to pair programming because there's pros and cons to literally every decision that we make. Thank you so much for watching. If you thought this was helpful, please feel free to share it with other people. And of course, if you have questions on software engineering, whether that's working in teams, building software, it could be career related, please leave them in the comments below.

Or you can do as this person did, go to codemute.com, use the question submission form. Happy to try and answer for you. Otherwise, you can send a message to dev leader on any social media platform. If you can't find me on one of them, find me on another one and message me so I can start posting on that platform as well. Thanks so much. I'll see you next time.