I’ve been working in programming for a few years and I think I really dislike Pair Programming; I understand how it is but I often find it mind-numbingly dull. I have a feeling I’m doing it wrong but I feel like as a part of a dev team tasks should be broken into discrete enough chunks that a single person can just blitz through the work… Maybe it’s just me, what are y’all thoughts on the matter?
If you have two devs pair programming, at least one of them is being slowed tremendously. It should be used very sparingly and only in junior/senior mentoring attempts. Putting two senior devs on pair programming is nearly always just slashing your dev productivity.
I’ve seen devs take 3 days to write code in pair programming that either one could’ve completed on their own in 4 hours or so.
No you’re not weird, pair programming is not one size fits all solution.
EDIT: To be clear, I still find value in pair programming, but a mandatory pair programming, for me is quite absurd. It should be organically happening, for example, a junior asking for help from senior.
I have found it quite effective while pair programming (senior to junior mentorship) to say OUT LOUD exactly what I’m changing and why I’m changing that. This allows others to more easily follow your train of thought and can lead to good discussions rather than turning PRs into essays.
However, as other comments have mentioned, this can get exhausting.
Not at all. I find it useful for certain tasks, but I’m a huge introvert and spending a long period of time with someone physically exhausts me to the point where I can’t muster coherent speech or thought. Depending on the depth of thinking required too, it’s often better for me to do that individually then bring my findings to someone else to validate.
I found it effective but exhausting. Did it for a full year, full time in an XP software shop. Burned out, needed six months in a low-pressure solo work team to recover.
Pairing wasn’t boring to me, though. Are you trading drivers regularly? Catching bugs as you go? Thinking out loud and getting feedback as you consider options? Discussing the interesting bits, like debating pros and cons of different design patterns? Parallelizing the boring bits so you’re burning through it together quickly? If you ever find yourself quietly watching someone else do menial work for any great length of time without providing meaningful input, something is wrong.
It completely depends on what is being worked on. In my experience, it is well suited to nebulous work filled with unknowns, and Ill suited for mundane, well-defined work.
I will say pairing is quite exhausting, just in terms of how “on” you have to be for long periods of time. Running solo you can turn off and find that flow state.
Someone else will have a completely different opinion I’m sure. Yay software.
Pair programming is a weird thing. It’s either an awful, uncomfortable experience or one of the best things to happen. It’s a combination of the developers and the task that determines how that particular experience will turn out.
Pair programming should be required for both new employees and for employees who have given their two weeks notice. The first allows the experienced developer to help ease newer employees into the workflow. The latter helps bring an employee up to speed with regards to the leaving employees duties and tasks.
I’ve found pair programming to be fantastic, but only when used rarely in certain situations.
If you’ve got a good rapport with a teammate and a legacy project has landed in your lap neither of you understand, I’ve found pair programming to be the fastest way to figure out how it works. As you work together, you’ll both understand different parts of it better and be able to quickly figure out what’s going on. I guess this is probably less pair-programming and more like collaborative dissection of code though.
I’ve also used it to help onboard people on a project fairly quickly. This is more tricky and much less comfortable to do, so I do my best to stay in tune with what they need from me, and tends to be me coding for a bit and them following along and asking questions. Eventually, they want to start writing some code, and a day or so of switching back and forth is as far as I’ve usually taken that. I think it’s useful to break down barriers when working with (especially new) people, to make mistakes in front of them, and build good rapport.
I’ve not used it much beyond those situations, but I’d definitely use it in these ways again.
It’s a great tool for knowledge sharing, ramp up and debugging. Definitely not something that needs to happen on every story. Stuck on something or working on a weird bug? Get someone on a call and walk them through it. New team member or old susbsytem not many people understand? Pair the less knowledgeable person up with an SME for the first couple tasks so they can pick the SME’s brain while they work and get valuable context that might be lost in code or the story description.
It also doesn’t need to drag on. I find 30 minutes is best because as you approach an hour+ attention is hard to maintain. Get on the same page, learn a few things and once your making progress move to async communication.
Pair programming is a tool and only valuable if you know how and when to use it.
I’ve always felt that pair programming is more useful on early stages of a task, where there is enough doubt about implementation details and discussing them is worth.
This way it felt more of a meeting between two persons discussing details first, while testing them live to check if we were on track second, instead of programming first and discussing second.
By the time we stand on the screen without talking too much we just stepped aside and separate the task if needed.
Any other kind of forced pair programming feels wrong, either because the task was already planned enough to no create enough discussion, or because it was small enough and the discussion was not worth. I’ve found myself on situations where “we needed” to make a task in pair programming and was dull as you say.
I’ve always felt that pair programming is more useful on early stages of a task, where there is enough doubt about implementation details and discussing them is worth.
Is pair programming the right way to address unknowns around implementation? It seems like a brainstorming / whiteboarding session might be a better fit.
More like unknowns about implementation details. Defining in brainstorming sessions how we want a solution makes sense, but I don’t imagine talking about details.
I was referring more about discussing the details inside of an already defined solution, like, for example, trying to use a library, which one we use, or how would be implemented in detail something.
I hate it. I really enjoy programming, and don’t enjoy social niceties. And I definitely don’t enjoy someone looking over my shoulder all the time.
So that leads to 2 situations: I’m programming, but someone is looking over my shoulder and stopping me constantly (or doing nothing), or I’m watching someone else program and constantly frustrated that it’s not me.
Even during an emergency I’m often better off just doing my thing solo, and the other person using their own methods to investigate and fix the problem. Chat is still available to share information and progress without it being a constant annoyance.
The only thing I think it’s really good for is learning to program, and unless the people are the same level, it’s probably only good for 1 of them.
Yeah I’ve definitely had situations where its been useful, lime double checking safety critical algorithms or making sure I haven’t missed anything obvious. But a lot of the time in my current team it just ends up feeling redundant, especially since it’s a small dev team.
While I agree that pair programming doesn’t fit everyone and all situations. Especially as a developer gets more experience, or for things that could be considered “scut work”. What you’re describing here really doesn’t sound like effective pair programming.
One person shouldn’t be just “watching” the other program. Especially for extended periods of time. There should be some regular interactivity or collaboration. I have found things like the “driver / navigator pattern” helpful.
One person doing the coding and the other just watching or doing nothing doesn’t sound like pair programming to me. That’s just working alone with someone else in the room, of course it’s not enjoyable.
Pair programming requires a fitting task and some basic rules, most importantly that the person at the keyboard doesn’t just type as they please without consulting the other person - otherwise they’ll quickly be programming alone.
Writing code is a one-person, one-keyboard, one-computer at a time task.
I don’t mind if someone watches, and I don’t mind watching someone else, but actively engaging with another person while also trying to concentrate and solve the problem in front of me is worse that counterproductive.
I think it depends on what your team’s goals are for pair programming. If you’re using it to just ‘complete a task,’ then yes, I think it’s likely to be counterproductive.
The better benefits tend to be
Knowledge and practice sharing across the team
Highlighting and aligning mental models about a project and it’s associated code
Providing coaching/mentorship opportunities between people with different experiences and strengths (not necessarily between just senior and junior devs).
And, as with any activity, the more explicit you can be beforehand about why you’re doing it and what the expected goals/outcomes are, the more likely it is that you will find pair programming useful when it’s appropriate and recognize when it’s not.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
It can vary. At its best, it’s a good way to share knowledge.
But even when it’s useful, I find it incredibly draining. I can probably only do it for a few hours before I just stop being able to manage it.
If you have two devs pair programming, at least one of them is being slowed tremendously. It should be used very sparingly and only in junior/senior mentoring attempts. Putting two senior devs on pair programming is nearly always just slashing your dev productivity.
I’ve seen devs take 3 days to write code in pair programming that either one could’ve completed on their own in 4 hours or so.
No you’re not weird, pair programming is not one size fits all solution.
EDIT: To be clear, I still find value in pair programming, but a mandatory pair programming, for me is quite absurd. It should be organically happening, for example, a junior asking for help from senior.
I have found it quite effective while pair programming (senior to junior mentorship) to say OUT LOUD exactly what I’m changing and why I’m changing that. This allows others to more easily follow your train of thought and can lead to good discussions rather than turning PRs into essays.
However, as other comments have mentioned, this can get exhausting.
Not at all. I find it useful for certain tasks, but I’m a huge introvert and spending a long period of time with someone physically exhausts me to the point where I can’t muster coherent speech or thought. Depending on the depth of thinking required too, it’s often better for me to do that individually then bring my findings to someone else to validate.
I found it effective but exhausting. Did it for a full year, full time in an XP software shop. Burned out, needed six months in a low-pressure solo work team to recover.
Pairing wasn’t boring to me, though. Are you trading drivers regularly? Catching bugs as you go? Thinking out loud and getting feedback as you consider options? Discussing the interesting bits, like debating pros and cons of different design patterns? Parallelizing the boring bits so you’re burning through it together quickly? If you ever find yourself quietly watching someone else do menial work for any great length of time without providing meaningful input, something is wrong.
It completely depends on what is being worked on. In my experience, it is well suited to nebulous work filled with unknowns, and Ill suited for mundane, well-defined work.
I will say pairing is quite exhausting, just in terms of how “on” you have to be for long periods of time. Running solo you can turn off and find that flow state.
Someone else will have a completely different opinion I’m sure. Yay software.
Pair programming is a weird thing. It’s either an awful, uncomfortable experience or one of the best things to happen. It’s a combination of the developers and the task that determines how that particular experience will turn out.
Pair programming should be required for both new employees and for employees who have given their two weeks notice. The first allows the experienced developer to help ease newer employees into the workflow. The latter helps bring an employee up to speed with regards to the leaving employees duties and tasks.
I’ve found pair programming to be fantastic, but only when used rarely in certain situations.
If you’ve got a good rapport with a teammate and a legacy project has landed in your lap neither of you understand, I’ve found pair programming to be the fastest way to figure out how it works. As you work together, you’ll both understand different parts of it better and be able to quickly figure out what’s going on. I guess this is probably less pair-programming and more like collaborative dissection of code though.
I’ve also used it to help onboard people on a project fairly quickly. This is more tricky and much less comfortable to do, so I do my best to stay in tune with what they need from me, and tends to be me coding for a bit and them following along and asking questions. Eventually, they want to start writing some code, and a day or so of switching back and forth is as far as I’ve usually taken that. I think it’s useful to break down barriers when working with (especially new) people, to make mistakes in front of them, and build good rapport.
I’ve not used it much beyond those situations, but I’d definitely use it in these ways again.
It’s a great tool for knowledge sharing, ramp up and debugging. Definitely not something that needs to happen on every story. Stuck on something or working on a weird bug? Get someone on a call and walk them through it. New team member or old susbsytem not many people understand? Pair the less knowledgeable person up with an SME for the first couple tasks so they can pick the SME’s brain while they work and get valuable context that might be lost in code or the story description.
It also doesn’t need to drag on. I find 30 minutes is best because as you approach an hour+ attention is hard to maintain. Get on the same page, learn a few things and once your making progress move to async communication.
Pair programming is a tool and only valuable if you know how and when to use it.
I’ve always felt that pair programming is more useful on early stages of a task, where there is enough doubt about implementation details and discussing them is worth.
This way it felt more of a meeting between two persons discussing details first, while testing them live to check if we were on track second, instead of programming first and discussing second.
By the time we stand on the screen without talking too much we just stepped aside and separate the task if needed.
Any other kind of forced pair programming feels wrong, either because the task was already planned enough to no create enough discussion, or because it was small enough and the discussion was not worth. I’ve found myself on situations where “we needed” to make a task in pair programming and was dull as you say.
Is pair programming the right way to address unknowns around implementation? It seems like a brainstorming / whiteboarding session might be a better fit.
More like unknowns about implementation details. Defining in brainstorming sessions how we want a solution makes sense, but I don’t imagine talking about details.
I was referring more about discussing the details inside of an already defined solution, like, for example, trying to use a library, which one we use, or how would be implemented in detail something.
Pair programming is a useful tool but like all tools it can be misused.
Edit: Typo,
s/paid/pair/I hate it. I really enjoy programming, and don’t enjoy social niceties. And I definitely don’t enjoy someone looking over my shoulder all the time.
So that leads to 2 situations: I’m programming, but someone is looking over my shoulder and stopping me constantly (or doing nothing), or I’m watching someone else program and constantly frustrated that it’s not me.
Even during an emergency I’m often better off just doing my thing solo, and the other person using their own methods to investigate and fix the problem. Chat is still available to share information and progress without it being a constant annoyance.
The only thing I think it’s really good for is learning to program, and unless the people are the same level, it’s probably only good for 1 of them.
Yeah I’ve definitely had situations where its been useful, lime double checking safety critical algorithms or making sure I haven’t missed anything obvious. But a lot of the time in my current team it just ends up feeling redundant, especially since it’s a small dev team.
While I agree that pair programming doesn’t fit everyone and all situations. Especially as a developer gets more experience, or for things that could be considered “scut work”. What you’re describing here really doesn’t sound like effective pair programming.
One person shouldn’t be just “watching” the other program. Especially for extended periods of time. There should be some regular interactivity or collaboration. I have found things like the “driver / navigator pattern” helpful.
One person doing the coding and the other just watching or doing nothing doesn’t sound like pair programming to me. That’s just working alone with someone else in the room, of course it’s not enjoyable.
Pair programming requires a fitting task and some basic rules, most importantly that the person at the keyboard doesn’t just type as they please without consulting the other person - otherwise they’ll quickly be programming alone.
Not at all.
Writing code is a one-person, one-keyboard, one-computer at a time task.
I don’t mind if someone watches, and I don’t mind watching someone else, but actively engaging with another person while also trying to concentrate and solve the problem in front of me is worse that counterproductive.
It’s not as bad if you use separate chairs.
I think it depends on what your team’s goals are for pair programming. If you’re using it to just ‘complete a task,’ then yes, I think it’s likely to be counterproductive.
The better benefits tend to be
And, as with any activity, the more explicit you can be beforehand about why you’re doing it and what the expected goals/outcomes are, the more likely it is that you will find pair programming useful when it’s appropriate and recognize when it’s not.