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?
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.
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
- 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.
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’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.
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 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.
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.
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.
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.
I’ve had useless paired programming sessions and great ones. Definitely depends on the person and the problem.
A bit from an ops-side, but I think it applies. I think pair-work, pair-programming, pair-troubleshooting is a tool for specific situations. It’s amazing in some places, and an exhausting waste of company resources in other places.
Like, if we’re in a hard situation with many unknowns and possibly horrible consequences of mistakes. Critical systems down, situation is weird. Or, implementing config management for something entirely new. Or, trying out new code structures, ideas. That’s when being two is great. You can bounce changes you make to the system off of your copilot, so you can be very safe while being fast. You can have two opinions about shaping a piece of code and APIs. You can iterate very quickly if necessary.
On the other hand though, there are things that require deep thought. Like, I had to figure out how 4-5 teams use an infrastructural component, what’s the live cycle of the component, when to create it, when to delete it, how to remove it. It ended up being twelve lines of code in the end, but like 1 phone call every two lines of code, and an hour of thinking per line of code. Pair programming would not have been compatible with this.
Or, the third kind, is crunch work. The best way to do crunch work (besides automating it) is to just put up headphones, find flow and hammer it down. Have it reviewed later if necessary. But why would we need 2 guys following the same runbook for the upteemth time?
It’s a great tool to share knowledge and to handle critical tasks with high error potential and I wouldn’t want to miss it for that. But it can be overused in my book.
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 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.
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 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.
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’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.
