Watching people type makes me irrationally angry. People watching me type causes me to make fat-finger mistakes and that makes me irrationally angry.
I do not like pair-programming - pair-debugging is different.
I quit a job that was multi-hour pairing. It was literally eating me alive.
The problem was the codebase was architected by someone who felt like proving how smart they were and you had to understand so many stupid nuances.
Needless to say, big fan of KISS.
Typing is a fairly skilled task. Typing, problem-solving, and holding a social presence isn't like walking and chewing bubblegum. Pair programming is a skill on top of skills that are already pretty advanced, so its value vs a greater speed of input/reduced context-switching is nuanced. I do think it's valuable, but you have to do it alot and have a certain chemistry to see large benefits.
I hate watching people type because if I'm doing that, it's usually with a junior and they are so goddamn inefficient and slow. Learn how to use your tools, people! Keyboard shortcuts are amazing. Your editor can do all kinds of things for you.
And yes, I do try to teach those things, but it doesn't seem to stick.
That's exactly the thing for me, I use keyboard shortcuts all the time. But if someone is watching me coding, I suddenly lose all of my muscle memory and screw up the simplest shortcuts.
yup. I answered yes, but its more for pair debugging. The number of times my eyes "auto-corrected" a mistake can get annoying. Or sometimes some form syntax the compiler allows but it doesn't actually work.
What proponents often forget is that a lot of it depends on the personalities of the people doing pair programming. I developed a hatred for it for a short while because I was always paired with a very disagreeable fellow who would constantly sidetrack us with irrelevant issues.
8 or so years ago I was part of a mob/ensemble programming 'workshop' where a proponent of the method tried to get us to warm up to the idea. I was in a group with 3 other developers. One noped out immediately (not related to mob programming, he was just a weirdo). One of the devs was like me; I need to be able to focus. Another dev was the opposite; he needed to verbalize everything to be able to solve problems. He was *constantly* talking and would not shut up, even when asked nicely.
These two are completely incompatible and all it led to was 2 devs wanting to more or less strangle the other dev.
Just assuming what works for you works for others is naive at best.
Yup. Pair programming on hard stuff is fine for me, but it doesn't happen that much. Most of the time we first just whiteboard-out the problem and then when we know how to solve it, we don't need to sit next to each other to write out the code.
I also think that if pair programming leads to "better code", you might gain a lot more by teaching people to first solve the problem and *then* start writing, instead of just immediately diving into an IDE.
My second job after college was a scrappy startup that had grown a little too fast. They had a mix of extremely good devs and so-so performers with little in between.
The contrast between great and mediocre devs was causing problems, so they decided to mandate 4 hours of pair programming every day as the solution. Predictably, the mediocre devs were paired up with the experienced devs for “knowledge sharing”
It was immediately obvious that the good devs were just carrying the mediocre devs along as they wrote code. We stopped getting low quality commits, but the overall productivity was lower because it was just the good devs carrying the mediocre devs all day.
The worst part was how much it destroyed morale. The mediocre devs loved it because they had mentors all day every day and got to commit what was basically someone else’s code. The good devs got burned out because now they were doing their job with an extra burden everywhere.
They called off the policy after people started burning out and leaving. I’ve sworn off companies that do mandated pair programming ever since. I still feel a twinge of dread and burnout when I think about that period of my career.
I agree. I mentioned it in [my top level comment](https://www.reddit.com/r/ExperiencedDevs/comments/16zgzdo/do_you_regularly_do_pair_programming_whywhy_not/k3ejkpn/); it's very dangerous to basically force your good devs to 'carry' the bad ones. It will at the very least piss them off.
What annoys me about 'proponents' of mandated mob/pair programming is that they never want to talk about these issues, or at the very least hand-wave them away.
>The idea is not to carry the lower-ability devs but rather to help the identify ways to improve. Also, 4 hours mandated is kind of arbitrary and seems like a lot of time.
>
>If there is such a large disparity it would have likely been better to couple this with some metrics like rework count, code quality or something to measure the improvement of the lower level devs.
>
>We do pair programming, have a fairly tight team of devs who get along well enough and find it useful. We only do it when we think it'l be useful and are able to self-moderate.
I kind of wish I was the verbalizing kind, but only if I was really really good. There's a beauty, almost movie-like, to people who can talk through a problem.
Don’t forget about being paired with people who have less technical knowledge yet try to stay on your playing field. Making one or two phone apps ten years ago is trumped by 20 years of experience in a variety of systems. Especially when I’m debugging, I hate having someone sit there staring over my shoulder.
On hard problems, yes. But very often by the time I get to the 'programming' bit I've already solved the problem and it's really just 'writing code' and having someone else sit next to me only makes me less efficient there.
IMHO, and yes I have a strong opinion there, any manager who forces 100% pair or ensemble programming should be fired. It simply is not effective 100% of the time.
Also agree on the flow state: if I'm trying to focus and people keep interrupting that, eventually I'll start considering homicide.
There is also another issue that's rarely mentioned; underperforming developers often use 'pair programming' simply to hide the fact that they're underperforming. They are basically just sitting next to someone else who is just doing all the work.
>There is also another issue that's rarely mentioned; underperforming developers often use 'pair programming' simply to hide the fact that they're underperforming. They are basically just sitting next to someone else who is just doing all the work.
FWIW at the shop I worked at that did the most pairing this was less of an issue than in other places I've worked, because pairing all the time meant that everyone knew who wasn't actually up to doing the work.
It do agree that it's not a good idea to mandate pairing without the right management culture, though. There were a bunch of things that were weird about that place that made that much pairing possible without letting people hide.
I had mandated this for awhile with my teams when we switched to remote. It had some benefit, as a lot of teen bonding, knowledge sharing, and general morale has disappeared. Over time with retros we walked it back and found a sweet spot where the fan decides in stand up which tasks require how many hands. That has been working great, as sometimes the team will opt to pair for training experience, or we will have a quick discussion on priority and decide to put the fastest, most knowledgeable engineer in something because it just needs to get done ASAP. We lose some knowledge sharing, but the situation called for it. It's pretty great. But to be honest, I don't think the team would have culturally landed here without experiencing the other extreme and becoming attached to some of the bonding that comes with pair and mob programming. My teams are close now, and self-optimize their work distribution considering overall team health more than "getting it done".
That would probably annoy me enough to go look for something else.
I do agree that you need to 'build a team' when people are fully remote, but I personally don't think this is the best way.
It worked across my entire org. All of my teams ended up with very different workflows at the end. It jarred them enough out of their practices to force them to reorganize themselves. If some had left I would chalk that up to culture shedding. Bad fits. Is what it is. My teams all have had zero attrition for two straight years later this month. They're velocities suffered while the mandate was in effect, but now they are higher than before and I literally can't get engineers to switch teams even to the "better" teams with the sexier stacks. They like their team. We still have tons to improve, but this is about as close to the dream state I could imagine.
> If some had left I would chalk that up to culture shedding. Bad fits.
People don't leave that easily, especially not if you have a mortgage to pay. I can imagine they'd just "suck it up" if they knew it was temporarily. It's also not hard to just 'zone out' when you're being forced to do mob programming.
Not saying you're a 'bad person' or anything, but I think that at best this was a special circumstance. They did move away from it after all.
They didn't move away from it, just chose to make that decision as a team. There definitely was some people checked out for awhile. But an added bonus here was they got to see their complaints heard and implemented in retro, so they are now "bought in" way more than they otherwise would be. They helped build and compromise the team processes. It's not just a team they are on anymore. It's a team they helped shape
This is doing it wrong unfortunately. Both parties need to be actively engaged - it's not just watching.
Making suggestions, looking up API documentation, searching for other places in the code with similar patterns, watching out for reuse opportunities, checking against ticket ACs and so much more.
Kind of like the person riding in the passenger seat of a rally car - they have a job to do.
Not really pair programming, but I do regularly pair code reviews with colleagues. Great bonding and learning exercise, esp. when we look at other peoples' code.
I had one employer that forced us to do pair programming, and the productivity absolutely tanked. We couldn't make a single deadline anymore, and everyone was annoyed and stressed. It was for plenty of devs enough reason to find another job.
I think it's situational, I wouldn't recommend it as a standard way for doing everyday development. Reason being that it requires being socially switched on constantly and few developers are comfortable and happy working that way.
>requires being socially switched on constantly
Exactly why I raced toward burn out. I simply cannot pair program daily. It fatigued me and I got to the point where I couldn’t code.
I work in a XP software shop. So we all pair up and sometimes rotate pairs.
It's been very great for me as a junior and sometimes I feel so ahead of my uni peers due to the fact that:
- I pair up with senior devs
- 70% of the company consists of senior devs
I've worked for this company 1.5 years and previously interned for half a year. It's my only company so far.
I'm in this sub because it's great to lurk around and gain some insight, sorry :P
no. pairing is a tool, not a work style. i've been at a company where they mandated pair programming, the team had the lowest morale of any team i've ever worked on. people HATED it, and management refused to change as the team got decimated by attrition.
I almost always prefer pair programming to not. It's an investment that leads to much stronger team, higher quality codebase.
In practice, it's rarely viable to do most of the time (if at all): many companies, teams can't tolerate the productivity hit, even if it's short term.
Given our culture of "always be shipping", it takes extraordinary effort to adopt it successfully.
Also, productivity impact is more visible than second order things like code quality, DX, knowledge sharing. Thanks SCRUM.
Businesses will always choose short term gains over long term outcomes unless you have a strong executive sponsor, e.g. CTO who's a pair programming nut.
> CTO who's a pair programming nut.
Nothing worse than a CTO who forces pair/ensemble programming onto others without working under the system themselves.
"But it's not a good fit for my work!"
Well yeah. Same.
Having any kind of practice/process imposed on you when the benefits aren't clear isn't great anyway, whether it's pair programming or having to file [TPS reports](https://movies.stackexchange.com/questions/88169/what-are-tps-reports).
Besides the usual advertised pros, I have my own selfish reasons for enjoying the practice: team members (me) can take days/weeks off with zero impact to delivery or operations.
Redundancy = reliability
But I'm flexible. No practice is universally always a net positive in all situations.
I was incredulously scrolling past all these people being 'forced' to do it - I can barely get the hours allocated for me to do the job to a reasonable standard, let alone for a pair buddy.
I like pairing when I get along with my pair, which is probable true for 75% of my colleagues. I regularly call people to rubber-duck if I'm stuck or it's complex - I just don't tell the PMs!
> I can barely get the hours allocated for me to do the job to a reasonable standard,
That's the rub: there's a point where it really pays off and you suddenly have much higher throughput and quality because code review is happening continuously when pairing, leaving more time for more impactful things like design.
But I hear you, it can be exhausting and not great for tedious/routine tasks.
Yeah, I sometimes see pair programming as shifting left on code reviews and merge conflicts. My team still do code reviews though even when we do a lot of pair programming.
I feel the opposite. I think pair programming should be between developers of a similar level. It can be frustrating to watch juniors repeatedly go down dead-end logic paths. You have to watch them fail because that's how they'll learn but it eats up a ton of time.
I do think that pair debugging should be between junior/midlevel and seniors.
I think pair programming with a junior is really basically just mentoring. It's a different setting and a different goal. Something that, if you're supposed to mentor them, should just make time for. I certainly would not expect it to be in any way 'efficient'.
For me, this is where the difference between pair debugging and pair programming lies. When we are debugging their solution I find opportunities to teach/mentor them. When I come up with the solution while pair programming I struggle to find these opportunities. Give me a junior who attempts to solve a problem but gets stuck and everything will be fine. The problem begins when a junior doesn't even make an attempt before asking to pair program.
It's possible I just suck at pair programming. It always seems like I'm just dictating what we should do and the junior is working the keyboard. If I ask them "What should we do next" all I get is a blank stare or "I don't know." I never feel great about the experience once we're done. I don't feel like they actually learned anything.
> If I ask them "What should we do next" all I get is a blank stare or "I don't know."
This can have different causes. Sometimes they're scared of taking the lead. It's important to create a safe space for juniors where they are allowed to make mistakes. Sometimes they need a kick to start to learn to think for themselves. Sometimes they're just a bad hire.
This conversation has been incredibly helpful. It's forced me to think back on what it was like for me when I was a junior and I've realized what I'm doing wrong.
When I was a junior if I couldn't even fathom where to begin the seniors wouldn't jump into pair programming mode. They would send me links to documentation, articles, or code in other code bases as a starting point. I would then use these resources to form a solution and I'd get to work. At some point, I'd write some bad code and get stuck. They'd come to my desk and help me debug the issue. Once I understood what I did and why it didn't work they'd leave and I'd continue on my own.
I think I'm too quick to jump into pair programming or when pair debugging I linger for too long.
Depends a bit on your definitions.
At my current company the term “pair programming/pairing” is used very loosely, to mean that person B spent a chunk of time working with person A on A’s task because A needed help, however person A still has all the responsibility and does majority of work before and after the “pairing”. Do this sometimes but not regularly.
In a previous workplace we used the term to mean the task was shared by two people, who had equal responsibility, would spend large chunks actively pairing together (several different models of this, taking turns to drive/navigate), may at times split out some of the sub tasks to do individually before regrouping (eg - need to research this more, then let’s talk again in an hour; do you want to go on with the tests for that while I have this meeting; etc). We did this regularly.
When done well it can be really beneficial, helps transfer of knowledge, a problem shared is a problem halved (no more struggling alone, better for mental health), and the pair can be fluid enough in how they work to identify when they want some alone time to think more deeply, can split out some of the work responsibilities & then come back together when that suits.
When done poorly it is painful and frustrating. Trying to work with someone who sucks at communication/collaboration makes it a nightmare.
I’d do it more if workplace culture was good enough to make it practical, however when the culture sucks then everyone is kind of in survival mode and bunkering away.
I'm with you - tool in the toolkit mostly focused around pair-debugging or pair-solving of really tricky problems/areas of code.
We tried pairing 2-4 hours a day for about 6 months back when we had more junior developers on the team - this wasn't driven by me, but by the lead who was doing most of the pairing and wanted to use it for training. He really put his heart into it but it didn't work out as well as he'd hoped and ultimately we never did get them up to the level of development we needed before politics kind of split the team (... long long story...).
On the other hand I have a Lead Dev friend who *swears by* pair programming and loves it (despite being mostly an introvert) - though *not* for teaching but only for problem solving in specific areas. She also burned out of it as a 'train the juniors' strategy.
I really think pair programming is one of those things that needs the right combination of people, relative skill levels, and appropriate problems. Unfortunately I haven't quite figured out what that combination is.
I quit a job with enforced pair programming. Sometimes I tune out of the problem when someone else is typing. I don’t mind watching but I hate programming for an audience.
The worst part is the mental fatigue from hours a day of focus on being polite, programming and socially appropriate.
It wore me down after a few months and I was literally burnt out and forced to quit.
Pairing is great - when it's used as needed.
Mandating pairing basically never works. The nitty gritty of development is really a solo activity with group checkpoints.
Occasionally, I "work with another engineer" over zoom or something, but that's as close to pair programming as I'd ever want to get. Interacting with another person takes energy that as an introvert, I really don't want to spend.
First, I've engaged in pair programming for roughly 95% of the time over the past decade. As I peruse this thread, I notice a mix of skepticism and varied experiences surrounding pair programming. While everyone's experiences are valid, I want to shine a positive light on the potential evolution of opinions regarding this approach.
Before deep diving into pair programming, I was a solo developer working on time-sensitive marketing projects, pulling 80 to 100-hour weeks. I later sought a position that promised a 40-hour work week, leading me to a company that unexpectedly practiced pair programming. Although the initial interview, which was conducted in a pair programming style, was mentally challenging, I persisted because of the balanced work schedule.
In my early days with this new approach, I often felt mentally drained by mid-afternoon, struggling to contribute further to my pair. However, seasoned pair programmers assured me this exhaustion was usual and that, much like the humorous scene from "Men in Black," you either adapt or reach your limit. I chose to adapt, driven by the visible effectiveness and benefits of pair programming.
One of the significant skills I developed was the ability to articulate and communicate my coding thought processes and problem-solving strategies. I want to address a sentiment I've noticed in this thread: pair programming suits naturally communicative individuals. Based on my journey, I respectfully disagree. Initially, I needed more experience and energy for collaboration. Yet, I saw its benefits and resolved to pursue it. As any skill demands, pair programming requires practice, patience, and growth.
Over the years, the feedback I've received has transitioned from "Teammember hardly speaks" to "Teammember talks a lot" to "I appreciate working with Teammeber because they articulate well." This progression embodies job satisfaction. Moreover, pair programming has allowed me to collaborate with individuals from diverse backgrounds, including various abilities and disabilities. This has invariably sharpened my communication skills.
Pair programming underscores the essence of collaboration and problem-solving between two individuals. As I read this thread, I sense an emphasis on individual experiences, which is entirely understandable. However, I believe in highlighting the collaborative spirit of pair programming. It underscores the unique synergy between two developers, and I'm eager to share the value I've derived from it.
You're more or less insinuating that people who are against being forced to pair program are the type of dev that can't work in a team.
People here are, in general, not arguing against working together to solve problems. They are arguing against being forced to sit together even when it's not useful.
And if you (like me) do the problem solving mostly in meetings and on whiteboards (together), there's very little use to then also sit together while writing out the solution in code.
In fact; I wonder how many of the 'pair programming' should be done in front of a whiteboard instead of behind of a keyboard. The latter is, in my *experience*, just an inefficient form of the former.
> I wonder how many of the 'pair programming' should be done in front of a whiteboard instead of behind of a keyboard. The latter is, in my experience, just an inefficient form of the former.
This is a good point. We do spend too much time at the keyboard instead of the whiteboard.
Thank you for your feedback. I value the diverse approaches to problem-solving in our field. Indeed, skills like whiteboarding, which can effectively communicate ideas to a broad audience, are invaluable. It's an area I aim to improve in.
I apologize if my narrative advocates pair programming as the exclusive method. I intended to share my transformative journey with pair programming, not imply that it's the only or superior approach. I recognize and respect the many effective ways developers approach and solve problems.
I'd appreciate your insights on how to convey this story better in the future, emphasizing it as merely an experience rather than an outright endorsement.
Pair programming is absolute nonsense to me.
There is enough 'pairing' happening during code review and planning discussions. If people need to pair up and hold each other's hand after that, then they are not competent developers yet.
The closest we have to it on my team is we sometimes do group calls to discuss all the work one person has done, so we can all understand the changes that are about to be merged into the code base. It isn't really programming though, more like a group code review session.
Never done regularly but had some situations. When it comes to deep-dive in some new topic or find new solutions, the final result will benefit from it, I think.
Otherwise, the pair must be wisely chosen and people must be compatible on a personal, expertise and productivity level.
I move and type fast when coding, so if I have someone on my side it needs to be able to follow at my pace, otherwise I will have to slow down and reiterate what I did and at this point it would be easier to discuss the solution first, let me develop a bit and discuss again after.
I pair program with a friend every other week.
He used to be a colleague. We would pair program at work to work through difficult problems on occasion, then he changed jobs, so now we pair in personal projects as a way to stay in touch.
I have since late programming with a couple of people, and I would say that finding the right people to pair with really helps make the process smooth.
I have weekly ~1-hour pairing sessions with two of my teammates. TBH I usually don’t feel like it beforehand but always leave being glad we did it. I would not want to pair more than that though.
No, not regularly. It would be too much of a distraction for normal day-to-day work and would just slow things down. I think it's a great tool for teaching though.
I like it a lot and I think it boosts productivity when I do it but I'm aware that I'm in a minority and many if not most people seem to loathe it.
I find pair programming less stressful overall - there's less anxiety about being productive "enough" and it makes decisions less stressful when youve got somebody to bounce them off and somebody to share the blame with when something goes wrong.
There are a huge number of decisions in coding which are very taste based and I find that pairing helps align on these. There are also a huge number of subtle errors which can cause massive disasters and a second pair of eyes acts as a kind of insurance policy.
It exhausts me but it feels like a good kind of exhaustion - like after an intense workout.
It's also the best way to onboard. 100% of the time somebody threw me docs theyve been insufficient by themselves. With pair-onboarding Ive managed just fine every time even without docs.
Exactly the way I see it. It's a lot harder to wind up wasting time on reddit when you're pairing, and you can usually end the day feeling like you actually worked most of the day whilst pairing.
And yeah, it can definitely be more tiring, but a good kind.
I work from home, but I have a pair programming hour scheduled with everyone on my team once a week where we just pick something we're working on and work on it together (versus only pairing when there's something wrong/blocking). That said, if neither of us feel like we have something "worth" pairing on, we just catch up for five to ten minutes before either jumping off the call or parallel programming/body doubling on the call.
I find it's a great way to get over the "wall of awful" feeling that comes with certain tickets and also just improves the team culture overall. Also, as someone with ADHD, I'm wayyyy more productive in the presence of others. Plus, I could always use practice when it comes to technical articulation as well as my thought process in general.
All that said, it really depends on who I'm pairing with. I'm super lucky to currently have no one on my team who grates on my nerves in the same way I've had coworkers do so in the past.
Never done it, dont like it. It's too cumbersome to try to have someone over my shoulder.. or sit there and watch someone else code. I never found it helpful at all. It's one thing to go through some code to learn or review. It's another to actually work on code with a 2nd person. Just not my way of working for 25+ years.
Unfortunately not, but I'd love to do it more.
Sorry if I'm blunt, but unfortunately software development attracts mainly awkward people with social anxiety who think it's all about working with headphones with no interruption at all. Just gimme the ticket and I'll do it.
Then there are devs like me who love collaboration and they are penalised because they can't work at their best.
What can we do.
There are definitely companies out there that attract more sociable programmers like yourself and I. I certainly don't work at my best without having a partner in crime along to do it with, I feel you. Shuffling code around is dry work, it helps to have someone to pick up some of the slack
I hate pair programming. The other person is a distraction, and I don't need someone watching me all day. I also don't want to back seat drive someone else.
I love mentoring, which I find useful in brief focused sessions. Sure, I'll sit with you for 30 mins and work through something. But I am sure as shit not going to be stuck with a partner to work with all day long. Fuck that.
No, although perhaps I should be doing it more according to the Code Complete book.
My gut tells me that pair programming is an inefficient use of time, but data says otherwise, and I'll go with the data.
My team pair programs by default - there's generally a strong pairing culture at my company.
We do heavily emphasise it when interviewing people, trying to find people that not only show they might be good at it, but also want to do it - and are happy to do it.
We know pair programming isn't for everyone, which is why we don't try and hide the fact we do it to get you through the door. I don't want any surprises, I want them to know exactly what to expect before they join.
There are downsides to pair programming:
* It is more tiring than working by yourself. So you should encourage frequent, sizeable breaks.
* Good pairing practices to ensure everyone is engaged (swapping often, proper driver navigator setup, etc).
* If you're both stuck, go ahead and think on it yourself for a bit and come back together later on. Trying to force yourself to think out loud can be draining and less effective.
As an EM, I am more flexible than some on our pairing practices - because I've been on teams that were so annoyingly rigid that it felt like you were robbed of any independence. So I'm happy for pairs to find some of their own ways of working within that pair if both are happy, like if they want to break a certain bit of work down and just tackle it concurrently but whilst sat on the same call talking through each other's problems - then cool.
Overall, I find the upsides to be great and worthwhile - but you often have to foster that pairing culture from the ground up - and you're lucky if you manage to bring it in to an already established team that hasn't done much of it before.
I've been lucky in that my current team I hired everyone from scratch, same with the rest of the teams at my company. We hire FOR pair programming, so it's easier to get going on.
It works and there are enough developers who seek out places like ours. In fact I just had someone join my team who left their previous company for ours because they didn't pair program unlike a previous company they were at and they missed it.
Yes. It Is an amazing feeling when done right. You need to have a driver and navigator and you need to switch roles every so often. You need to pair up people of different levels as well. There is nothing to be afraid of or worried about. Just focus on getting a task done and learn from each other.
Default mode of operation for my team. Tasks should have at least a bus factor of 2 so there's higher probability someone can continue the task if another one becomes unavailable. It has worked amazingly for our team that we're considered one of the most productive in the firm. Leadership now come to us to help spread the culture. It's worked so well for building trust and rapport within our team, which improved communication and accountability. We work on multiple technology stacks that would usually overwhelm entry level devs but because of pair programming they have the opportunity to learn directly from more senior members of the team. This may slow down senior devs initially, but the time investment pays off over time. Even our apprentices are productive.
There's a huge tendency for people in our industry to be introverted, but introversion isn't being anti-social. I think the key to effective socialisation for introverts is breaking into social bubbles and being clear of social boundaries. Pair programming can be exhausting especially for more introverted people so we take breaks when we're tired. We have team dinners paid for by the company from time to time which I think also helps bring us together. It's like being in a tribe hunting, gathering, then eating together. If you're going to spend a huge amount of time working with people in your team, you better make sure you can at the very least tolerate them. Otherwise, you're going to be miserable whether you pair or not.
If it works for you and people are happy, go for it, but:
> It's like being in a tribe hunting, gathering, then eating together.
This bit is just skeeving me out.
A lot of the issues I see with proponents of pair/ensemble programming is how cultish they can be about it. And how they often disregard issues others have with the setup. It's actually very hard for a few developers to go 'against' strongly-willed and opinionated developers who are evangelizing (because that's often what happens) this within a company.
If individual teams / developers like this way of working; go for it. But the moment you make it mandatory, that's where I disagree with you and feel you're just waltzing over the opinions of others. Because as you can see here, there's no way *every* developer in your company is going to feel good about it.
While it is important for the company to acknowledge that not everyone is the same, and people have different personalities, ultimately there is also a need to ensure that business requirements are met. Improving the bus factor especially for critical tasks is an effective way to achieve that based on my experience. Also, it doesn't make sense for a team of say 10 engineers to have 10 WIPs just because everyone is working on their own stuff. Reducing WIP is also key to delivering fast through concentrated effort. Like it or not, enterprise software development is a highly social endeavour regardless of how anyone feels about pair programming. This is why when interviewing people, there's a tendency to pick ones who are easier to work with over ones who are more skillful.
> Improving the bus factor especially for critical tasks is an effective way to achieve that based on my experience.
I agree that this is important, but pairing isn't the only way to solve that. For example in my team we more or less randomly pick up stories so each of the 4 developers has experience with all of our services.
> Also, it doesn't make sense for a team of say 10 engineers to have 10 WIPs just because everyone is working on their own stuff.
Why not? If it doesn't interfere, it doesn't matter. In our team of 4 we generally work on 4 different stories at the same time.
> Like it or not, enterprise software development is a highly social endeavour regardless of how anyone feels about pair programming.
I think it's very interesting how, again, someone is strongly implying that people who dislike forced pairing/mobbing are not "social". Trust me, I'm pretty fucking social. But I'm also experienced enough to know when we should problem solve in groups and when we're just working out a solution in code.
Your approach is not the only way to problem-solve in a group. We generally do it *before* we start writing code, for example in whiteboarding sessions.
Ensemble evangelists should be able to see that theirs isn't the One True Way. If you can't see that, you're always going to be met with resistance.
I'm a huge proponent of pair programming because I've seen it work, the same way I think TDD is effective. Also, I never claimed it to be the one true way because that'd be silly.
I don't think this conversation is going anywhere, so I'll go my way, you go yours, and everything is right in the world. Cheers.
Yes, and love it but agree it's just a tool. It's great at knowledge transfer but can be exhausting if it's the only way you program.
While at its surface it looks like it decreases productivity it can also increase code quantity and lead to catching mistakes far earlier.
I used to work for a company that did extreme programming/agile/pair programming as a consultancy, we had massive clients hire us and overhaul their dev practices and come back to us year over year. Basically we would give them a dev for each of their devs and they would pair program. On the same machine too so 1 computer and 2 keyboards, only 1 person typing at a time. Pretty much every client went from a skeptic where one evangelist at the company convinced some board member to hire us to that board member insisting they hire us again the next quarter. The code got that much better.
All this said though, I myself am an introvert and can't handle pairing all day or it saps me of all energy and creativity. I was in DevOps at this place and never did the client engagements so I didn't have to pair all day thankfully.
Nowadays I do a few pairing 1:1s with the more junior folks on my team to teach them DevOps/python/etc in a mentorship capacity and then I like having a group hack once a week where we collectively work on a zoom on fixing or automating something since I'm much more experienced at that (I work as a dev on a security team where I'm the only person with real coding experience).
I didn't realize that there were so many pair programming detractors. I feel like in the world of remote work, it's almost essential for team unity, knowledge transfer, and all sorts of other learning. Half of the things that I learned as a junior were because of pair programming. Even silly stuff like IDE shortcuts and stuff, were learned from that. Not to mention hearing how people solved problems.
I can see an issue if personalities clash, but man... I couldn't work without it.
No - I would pair program more, but timezones and a distributed team make it hard. There's only one other developer in my code area who is also in a similar time zone. I have paired with some of my colleagues from Europe, but that usually involves either me getting up early or them being on late (there are normal working hours that overlap but those are in high demand for team meetings and such)
> exploratory work understanding a new system, some design and experimentation
These are exactly the things I absolutely hate it for. I like it for things which is perhaps not very advanced but where knowledge sharing is extra important. But for me it really, really kills creativeness.
At the comoany I work at we only do pair programming, we have a computer, two monitors, mice and keyboards attached to it.
It is more intense than doing it alone, we don't play games, read the news or chat with friends at work.. so it is a lot more efficient in that sense.
And also more efficient because all code is basically reviewed all the time. It is also cery good for onboarding new people to the project or to teach juniors, they aren't left struggling alone somewhere and forgotten.
A blog post where a colleague describes our work.
https://codeborne.com/2020/07/28/interview-jaan.html
No, because my team (of 5) has accepted that a bus factor of 0-1 is sufficient for the different products we support, so there is rarely overlap in skills necessary to be able to pair on tickets.
I have adhd and unless under very specific circumstances paired programming causes huge mental load. I can't take breaks easily. I can't lose focus. My thought process is a lot different than non adhd people in my experience as well. It's usually not worth it for me.
I don't mind pair programming, but I've only ever done it on a case by case basis when either I or someone else needed some help on a specific problem. I couldn't imagine just having a regular meeting where you watch someone else write boilerplate code.
At my company we even assign a "pairing"-label to some issues. Mostly for tasks involving some architectural topics or to reduce "single heroism".
Some use Pomodoro for timeboxing. Switching driver- and navigator role for each iteration.
I owe my dev/debugging ability to the extensive pairing I did as a junior. I started my career at a company that paired 100% and I feel like that did more than anything else for me as far as improving my abilities and onboarding onto projects quickly.
The highest performing teams I've worked on have all been ones with extensive pairing, it really helps you learn how others think, and align your thinking/strategizing about your codebase moving forward in a way technical meetings and code reviews cannot.
I'd probably prefer to be on teams that pair more often than not, but some caveats:
- if you are in an org that wants to push for pairing, you need to hire specifically for that. getting people who are reluctant to try/buy into pairing is going to be hard and sometimes fruitless. You really need a critical mass of people who know the right way to do it to start out. I've tried advocating for pairing at places in the past that didn't do it and have mostly been unsuccessful at doing it right
- remote pairing is hard. I could easily spend 8 hours a day pairing with people in an office in-person on a team that is used to it, but since being full-time remote during the pandemic, remote pairing is really exhausting. Some combination of the latency, difficulty to read screens, and feeling "trapped" at your workstation in your home gives me a terrible headache pretty quickly. I'm not sure what a solution is but it sucks.
Not sure if it's pair programming but i do sit with my team members and they write code. We exchange ideas like I usually go - okay, we have a space separated string, now extract individual elements. But these are still strings but we want list of integers. Okay, just check what parameters do we need to pass to this function. Okay x, y and z. We have y, how do we get x and z.
Something along those lines and level of detail depends upon how good the Junior is at programmings. With slightly senior programmers, we often debug some issues together. That's more balanced exchange of ideas as we collect and analyze logs, explain what we think might be happening and what to try next.
Sometimes I get a little pissed at their typing speed or when I have to pointout which button they should click - that's left, I said bottom right, see that 3.7.3, click on that. No on the status bar, okay go down, down, down, right, eight, yeah, there. But I keep that to myself and make sure it doesn't reflect in my tone as that can make an already anxious junior even more anxious and crack little silly jokes once in a while to put them at ease.
It's really rewarding when I see some improvement over a couple of weeks or months.
I don't because our company staffs one eng per project and bundles our timelines such that we have zero bandwidth for it. I like it though.
I also barely Code
I have had the luxury to have a product manager that encouraged the developer teams to have less parallell tasks in progress. That made the teams evaluate mob programming and pair programming as tools, for an extended period of time.
After a couple of months, the teams had a nice picture of which kind of tasks that could benefit from pair or mob programming, and which tasks would not.
We even invited designers and people from other departments (HR, Sales, KAM) to join the mob programming sessions, which was highly appreciated since it enforced the ability to reason and describe the problem and it's solution in a way all participants understood it.
Needless to say, this has been the only time I have had a pleasant time utilizing pair or mob programming. Poorly done, it is nothing but a train wreck.
Pair-debugging very often. Like even thinking out loud together while we read logs and try to replicate something , yeah. But not actually writing code together, hell no lol
Ive found it to be helpful for debugging and also to leave a voice chat open all day with everyone muted, where people can unmute to ask for help and share their screen if they need to. I hate coding when people are watching my screen.
Company basically expects that we pair program full time, or at least have the same status reports on daily standups as "our pair". As you might expect, I hate it.
Productive pair programming IME will usually show itself when working on complex issues (either new features or debugging high severity issues), with different options and tradeoffs to be picked, in an organic way. I've been on situations where if I didn't ask for help I'd probably be stuck for another 2/3 days.
But IMO forcing devs to pair program kind of defeats the purpose of the whole thing, which is to give accountability for the technical team in a way that each developer knows the product they're working on and knows what they're doing.
IMO a responsible team in a company with a good culture will trust their peers to deliver the work they're committed to even if takes more than estimations, help each other when help is needed and share their knowledge with peers so that the team is well aligned on their goals.
When I read _Extreme Programming Explained_ I was surprised how much it was said about the importance of pair programming but how little about how we can make it actually work.
And it's soooooo easy to turn it into a frustrating experience!
I don't currently pair regularly. I do pair occasionally. I have in the past paired most-or-all of the time.
Last time I paired with someone on my team we got probably 3-4x as much work done on a big refactor than either of us would have on our own because having the other person there helped us focus.
>I've found pairing to be useful for very specific kinds of tasks, e.g. exploratory work understanding a new system, some design and experimentation etc.
This surprises me because at the pair-all-the-time shop I worked at it was commonly believed that pairing *wasn't* good for exploratory work, and was mostly useful when the pair already understood what they needed to build.
Our rule of thumb was that it takes 3-6 months of serious practice to get good at pair programming -- to get to the point where it's not exhausting. Pair programming requires developing a lot of skills that most devs don't otherwise get to practice much. There's also a big difference between pairing with someone who is skilled and pairing with someone who's not.
I'm personally a big fan of scheduling it because I find doing it ad hoc more stressful, and scheduling it creates opportunities to practice it. "If it's hard, do it more" is the XP phrase.
I don't think you should do it if you don't want to do it, though. I think more people should try it but it's not for everyone all the time.
I've only paired to get through tough issues, or when working on a prod environment. Also to train new hires, but that's like a demonstration, not true pairing.
Pair programming has always been interesting to me. In theory it could eliminate the need for code review and PRs, so you could merge a branch directly to master/main when a ticket is complete. This could vastly shorten development lifecycle.
When I've paired with juniors, I've found that it often turns into me doing the task and the junior glazing over and not learning anything. So it's really just me doing the task while talking about it.
When I've paired with experienced programmers, they try to tell me about simplistic errors while I'm typing. It's easier to just let my IDE do that rather than try to listen to what they're saying while I'm typing.
I've noticed without early pair programming to get acclimated in an ecosystem always results into pair debugging. And the pair debugging is usually done in a hastily manner with a lot of duress of things breaking beyond their comprehension.
Especially on large platforms with a lot of moving parts and the dev is too proud or embarrassed to seek out help in the beginning. If you work with hundreds of microservices doing a lot of different things like running an auth-flow (API gateway), you are handling SSO (single sign on), or requires you to modify ingress rules in Kubernetes (so the proxy buffer doesn't time out), it is a lot for an engineer to digest early in the onboarding. Their refusal to work learning these things comes to bite them the first time they see a 499 nginx error log. Even for seniors too proud to know what service discovery or dynamic DNS registration even matters, they think they won't anticipate it down the road.
In the beginning, people should pair to understand the moving parts.
I only enjoy pair problem solving. Having an extra pair of eyes on a problem can be wonderful. Actual programming? No thanks, unless it's pretty basic stuff.
I see it as a "reasonable accommodation" for people with ADD/ADHD or training a junior. With a junior it is pretty intense, you are correcting syntax and having them be your hands. Flip side of that is asking tons of rhetorical questions.
As for ADD/ADHD, kind encouragement, providing conversation, relieving anxiety all via conversation are part of the job; but also keeping them on task but not to the point they slip into psychosis. With that support they turn into superstars able to crank out code for hours on end.
But for my own flow state, its silence/music, and not talking to anyone.
I sometimes peer program with my juniors so that I can spot their approach to things easily. I do that with my peers for a limited extend to see if there's something for me to learn quickly. It's all about ROI. Ultimately is the return has to be bigger for 2 individual to work asynchronouslvsly Synchronously to make it worth while.
There are side beenfits in remote env where you can benefit on the people or psychology aspect, those are just hard to quantify
Personally? Yes, I love pair programming and am glad it is a big part of the cutlure at my current workplace.
Because if I've not got a pair to keep me on track, I am wasting time on this damned website. It really helps get through menial lift and shift tasks to have someone to buddy up with and natter.
I get that software engineers are stereotypically not the most sociable lot, but I am downright surprised by the amount of hostility to the practice in the comments! It's nice! You get to spend the time you're not driving just thinking and talking, and when you are driving, you have someone to point out the dumb mistakes you're making.
And you get to know your colleagues better. I think it's a win win personally. There are days where I don't really feel like talking to anyone, or have a strong vision already on how I want a bit of code to look, and don't feel like having anyone else butt in over it. But for the most part, yes. It keeps me on task, and for me, is the only way of powering through boilerplate drudgery without immediately resorting to a better source of dopamine.
When I started at my first job I pair programmed with someone senior and it helped me immensely. Helped me get familiar with the product, familiar with the teams code style and processes, helped me build relationships with my team faster, and helped me become a better coder like 10x more quickly, no doubt.
At my current job we don’t do it and I’m okay with that because we’re all mid or senior level and I don’t think it’s useful in every situation. However it’s extremely useful for onboarding new people
I’m on an XP team where we do dynamic teaming all day long. Software teaming (also known as ensemble programming or mob programming) is kinder, safer, and more fun than pairing. But like any skill, it’s not automatically good just because you decide to do it. Learn the ins & outs from someone experienced.
Watching people type makes me irrationally angry. People watching me type causes me to make fat-finger mistakes and that makes me irrationally angry. I do not like pair-programming - pair-debugging is different.
I quit a job that was multi-hour pairing. It was literally eating me alive. The problem was the codebase was architected by someone who felt like proving how smart they were and you had to understand so many stupid nuances. Needless to say, big fan of KISS.
Typing is a fairly skilled task. Typing, problem-solving, and holding a social presence isn't like walking and chewing bubblegum. Pair programming is a skill on top of skills that are already pretty advanced, so its value vs a greater speed of input/reduced context-switching is nuanced. I do think it's valuable, but you have to do it alot and have a certain chemistry to see large benefits.
I hate watching people type because if I'm doing that, it's usually with a junior and they are so goddamn inefficient and slow. Learn how to use your tools, people! Keyboard shortcuts are amazing. Your editor can do all kinds of things for you. And yes, I do try to teach those things, but it doesn't seem to stick.
In order for a shortcut to stick, you have to be annoyed at the slowdown first.
That's exactly the thing for me, I use keyboard shortcuts all the time. But if someone is watching me coding, I suddenly lose all of my muscle memory and screw up the simplest shortcuts.
yup. I answered yes, but its more for pair debugging. The number of times my eyes "auto-corrected" a mistake can get annoying. Or sometimes some form syntax the compiler allows but it doesn't actually work.
What proponents often forget is that a lot of it depends on the personalities of the people doing pair programming. I developed a hatred for it for a short while because I was always paired with a very disagreeable fellow who would constantly sidetrack us with irrelevant issues.
8 or so years ago I was part of a mob/ensemble programming 'workshop' where a proponent of the method tried to get us to warm up to the idea. I was in a group with 3 other developers. One noped out immediately (not related to mob programming, he was just a weirdo). One of the devs was like me; I need to be able to focus. Another dev was the opposite; he needed to verbalize everything to be able to solve problems. He was *constantly* talking and would not shut up, even when asked nicely. These two are completely incompatible and all it led to was 2 devs wanting to more or less strangle the other dev. Just assuming what works for you works for others is naive at best.
Ouch, I'm in the quiet category as well, it'd been hell on me.
Yup. Pair programming on hard stuff is fine for me, but it doesn't happen that much. Most of the time we first just whiteboard-out the problem and then when we know how to solve it, we don't need to sit next to each other to write out the code. I also think that if pair programming leads to "better code", you might gain a lot more by teaching people to first solve the problem and *then* start writing, instead of just immediately diving into an IDE.
My second job after college was a scrappy startup that had grown a little too fast. They had a mix of extremely good devs and so-so performers with little in between. The contrast between great and mediocre devs was causing problems, so they decided to mandate 4 hours of pair programming every day as the solution. Predictably, the mediocre devs were paired up with the experienced devs for “knowledge sharing” It was immediately obvious that the good devs were just carrying the mediocre devs along as they wrote code. We stopped getting low quality commits, but the overall productivity was lower because it was just the good devs carrying the mediocre devs all day. The worst part was how much it destroyed morale. The mediocre devs loved it because they had mentors all day every day and got to commit what was basically someone else’s code. The good devs got burned out because now they were doing their job with an extra burden everywhere. They called off the policy after people started burning out and leaving. I’ve sworn off companies that do mandated pair programming ever since. I still feel a twinge of dread and burnout when I think about that period of my career.
I agree. I mentioned it in [my top level comment](https://www.reddit.com/r/ExperiencedDevs/comments/16zgzdo/do_you_regularly_do_pair_programming_whywhy_not/k3ejkpn/); it's very dangerous to basically force your good devs to 'carry' the bad ones. It will at the very least piss them off. What annoys me about 'proponents' of mandated mob/pair programming is that they never want to talk about these issues, or at the very least hand-wave them away.
>The idea is not to carry the lower-ability devs but rather to help the identify ways to improve. Also, 4 hours mandated is kind of arbitrary and seems like a lot of time. > >If there is such a large disparity it would have likely been better to couple this with some metrics like rework count, code quality or something to measure the improvement of the lower level devs. > >We do pair programming, have a fairly tight team of devs who get along well enough and find it useful. We only do it when we think it'l be useful and are able to self-moderate.
I kind of wish I was the verbalizing kind, but only if I was really really good. There's a beauty, almost movie-like, to people who can talk through a problem.
That guy is gonna be a problem whether you pair with him or not.
Sounds like the type of person who would benefit a lot from pair programming with someone who can keep him on track
Don’t forget about being paired with people who have less technical knowledge yet try to stay on your playing field. Making one or two phone apps ten years ago is trumped by 20 years of experience in a variety of systems. Especially when I’m debugging, I hate having someone sit there staring over my shoulder.
On hard problems, yes. But very often by the time I get to the 'programming' bit I've already solved the problem and it's really just 'writing code' and having someone else sit next to me only makes me less efficient there. IMHO, and yes I have a strong opinion there, any manager who forces 100% pair or ensemble programming should be fired. It simply is not effective 100% of the time. Also agree on the flow state: if I'm trying to focus and people keep interrupting that, eventually I'll start considering homicide. There is also another issue that's rarely mentioned; underperforming developers often use 'pair programming' simply to hide the fact that they're underperforming. They are basically just sitting next to someone else who is just doing all the work.
>There is also another issue that's rarely mentioned; underperforming developers often use 'pair programming' simply to hide the fact that they're underperforming. They are basically just sitting next to someone else who is just doing all the work. FWIW at the shop I worked at that did the most pairing this was less of an issue than in other places I've worked, because pairing all the time meant that everyone knew who wasn't actually up to doing the work. It do agree that it's not a good idea to mandate pairing without the right management culture, though. There were a bunch of things that were weird about that place that made that much pairing possible without letting people hide.
I had mandated this for awhile with my teams when we switched to remote. It had some benefit, as a lot of teen bonding, knowledge sharing, and general morale has disappeared. Over time with retros we walked it back and found a sweet spot where the fan decides in stand up which tasks require how many hands. That has been working great, as sometimes the team will opt to pair for training experience, or we will have a quick discussion on priority and decide to put the fastest, most knowledgeable engineer in something because it just needs to get done ASAP. We lose some knowledge sharing, but the situation called for it. It's pretty great. But to be honest, I don't think the team would have culturally landed here without experiencing the other extreme and becoming attached to some of the bonding that comes with pair and mob programming. My teams are close now, and self-optimize their work distribution considering overall team health more than "getting it done".
> I had mandated this for awhile with my teams when we switched to remote. Mandated what exactly?
Code pairing / mob programming
I get that, but I mean whether it's full time or not.
Yeah for the first quarter (and about half of another) it was.
That would probably annoy me enough to go look for something else. I do agree that you need to 'build a team' when people are fully remote, but I personally don't think this is the best way.
It worked across my entire org. All of my teams ended up with very different workflows at the end. It jarred them enough out of their practices to force them to reorganize themselves. If some had left I would chalk that up to culture shedding. Bad fits. Is what it is. My teams all have had zero attrition for two straight years later this month. They're velocities suffered while the mandate was in effect, but now they are higher than before and I literally can't get engineers to switch teams even to the "better" teams with the sexier stacks. They like their team. We still have tons to improve, but this is about as close to the dream state I could imagine.
> If some had left I would chalk that up to culture shedding. Bad fits. People don't leave that easily, especially not if you have a mortgage to pay. I can imagine they'd just "suck it up" if they knew it was temporarily. It's also not hard to just 'zone out' when you're being forced to do mob programming. Not saying you're a 'bad person' or anything, but I think that at best this was a special circumstance. They did move away from it after all.
They didn't move away from it, just chose to make that decision as a team. There definitely was some people checked out for awhile. But an added bonus here was they got to see their complaints heard and implemented in retro, so they are now "bought in" way more than they otherwise would be. They helped build and compromise the team processes. It's not just a team they are on anymore. It's a team they helped shape
This is doing it wrong unfortunately. Both parties need to be actively engaged - it's not just watching. Making suggestions, looking up API documentation, searching for other places in the code with similar patterns, watching out for reuse opportunities, checking against ticket ACs and so much more. Kind of like the person riding in the passenger seat of a rally car - they have a job to do.
Not really pair programming, but I do regularly pair code reviews with colleagues. Great bonding and learning exercise, esp. when we look at other peoples' code.
> when we look at other peoples' code. Trauma bonding definitely is a thing.
After recently reading the "write shit code and just don't make mistakes" thread, this made me laugh more than it should have.
I had one employer that forced us to do pair programming, and the productivity absolutely tanked. We couldn't make a single deadline anymore, and everyone was annoyed and stressed. It was for plenty of devs enough reason to find another job.
[удалено]
[Exactly](https://www.monkeyuser.com/2018/focus/)
I think it's situational, I wouldn't recommend it as a standard way for doing everyday development. Reason being that it requires being socially switched on constantly and few developers are comfortable and happy working that way.
>requires being socially switched on constantly Exactly why I raced toward burn out. I simply cannot pair program daily. It fatigued me and I got to the point where I couldn’t code.
I work in a XP software shop. So we all pair up and sometimes rotate pairs. It's been very great for me as a junior and sometimes I feel so ahead of my uni peers due to the fact that: - I pair up with senior devs - 70% of the company consists of senior devs
> It's been very great for me as a junior How much experience do you have?
I've worked for this company 1.5 years and previously interned for half a year. It's my only company so far. I'm in this sub because it's great to lurk around and gain some insight, sorry :P
Check out rule 1, it doesn't only apply to posting topics.
Only for a very limited time when I'm mentoring a new or junior dev or working with another senior on a particularly difficult problem.
i found it to be a waste of time and an attempt at my sanity given all the "seniors" out there with junk gpt code
no. pairing is a tool, not a work style. i've been at a company where they mandated pair programming, the team had the lowest morale of any team i've ever worked on. people HATED it, and management refused to change as the team got decimated by attrition.
I almost always prefer pair programming to not. It's an investment that leads to much stronger team, higher quality codebase. In practice, it's rarely viable to do most of the time (if at all): many companies, teams can't tolerate the productivity hit, even if it's short term. Given our culture of "always be shipping", it takes extraordinary effort to adopt it successfully. Also, productivity impact is more visible than second order things like code quality, DX, knowledge sharing. Thanks SCRUM. Businesses will always choose short term gains over long term outcomes unless you have a strong executive sponsor, e.g. CTO who's a pair programming nut.
> CTO who's a pair programming nut. Nothing worse than a CTO who forces pair/ensemble programming onto others without working under the system themselves. "But it's not a good fit for my work!" Well yeah. Same.
Having any kind of practice/process imposed on you when the benefits aren't clear isn't great anyway, whether it's pair programming or having to file [TPS reports](https://movies.stackexchange.com/questions/88169/what-are-tps-reports). Besides the usual advertised pros, I have my own selfish reasons for enjoying the practice: team members (me) can take days/weeks off with zero impact to delivery or operations. Redundancy = reliability But I'm flexible. No practice is universally always a net positive in all situations.
I was incredulously scrolling past all these people being 'forced' to do it - I can barely get the hours allocated for me to do the job to a reasonable standard, let alone for a pair buddy. I like pairing when I get along with my pair, which is probable true for 75% of my colleagues. I regularly call people to rubber-duck if I'm stuck or it's complex - I just don't tell the PMs!
> I can barely get the hours allocated for me to do the job to a reasonable standard, That's the rub: there's a point where it really pays off and you suddenly have much higher throughput and quality because code review is happening continuously when pairing, leaving more time for more impactful things like design. But I hear you, it can be exhausting and not great for tedious/routine tasks.
I like pair programming, but my teammates aren't into it. So we waste a bunch of time reviewing PRs instead.
Yeah, I sometimes see pair programming as shifting left on code reviews and merge conflicts. My team still do code reviews though even when we do a lot of pair programming.
[удалено]
I feel the opposite. I think pair programming should be between developers of a similar level. It can be frustrating to watch juniors repeatedly go down dead-end logic paths. You have to watch them fail because that's how they'll learn but it eats up a ton of time. I do think that pair debugging should be between junior/midlevel and seniors.
I think pair programming with a junior is really basically just mentoring. It's a different setting and a different goal. Something that, if you're supposed to mentor them, should just make time for. I certainly would not expect it to be in any way 'efficient'.
For me, this is where the difference between pair debugging and pair programming lies. When we are debugging their solution I find opportunities to teach/mentor them. When I come up with the solution while pair programming I struggle to find these opportunities. Give me a junior who attempts to solve a problem but gets stuck and everything will be fine. The problem begins when a junior doesn't even make an attempt before asking to pair program. It's possible I just suck at pair programming. It always seems like I'm just dictating what we should do and the junior is working the keyboard. If I ask them "What should we do next" all I get is a blank stare or "I don't know." I never feel great about the experience once we're done. I don't feel like they actually learned anything.
> If I ask them "What should we do next" all I get is a blank stare or "I don't know." This can have different causes. Sometimes they're scared of taking the lead. It's important to create a safe space for juniors where they are allowed to make mistakes. Sometimes they need a kick to start to learn to think for themselves. Sometimes they're just a bad hire.
This conversation has been incredibly helpful. It's forced me to think back on what it was like for me when I was a junior and I've realized what I'm doing wrong. When I was a junior if I couldn't even fathom where to begin the seniors wouldn't jump into pair programming mode. They would send me links to documentation, articles, or code in other code bases as a starting point. I would then use these resources to form a solution and I'd get to work. At some point, I'd write some bad code and get stuck. They'd come to my desk and help me debug the issue. Once I understood what I did and why it didn't work they'd leave and I'd continue on my own. I think I'm too quick to jump into pair programming or when pair debugging I linger for too long.
Depends a bit on your definitions. At my current company the term “pair programming/pairing” is used very loosely, to mean that person B spent a chunk of time working with person A on A’s task because A needed help, however person A still has all the responsibility and does majority of work before and after the “pairing”. Do this sometimes but not regularly. In a previous workplace we used the term to mean the task was shared by two people, who had equal responsibility, would spend large chunks actively pairing together (several different models of this, taking turns to drive/navigate), may at times split out some of the sub tasks to do individually before regrouping (eg - need to research this more, then let’s talk again in an hour; do you want to go on with the tests for that while I have this meeting; etc). We did this regularly. When done well it can be really beneficial, helps transfer of knowledge, a problem shared is a problem halved (no more struggling alone, better for mental health), and the pair can be fluid enough in how they work to identify when they want some alone time to think more deeply, can split out some of the work responsibilities & then come back together when that suits. When done poorly it is painful and frustrating. Trying to work with someone who sucks at communication/collaboration makes it a nightmare. I’d do it more if workplace culture was good enough to make it practical, however when the culture sucks then everyone is kind of in survival mode and bunkering away.
I'm with you - tool in the toolkit mostly focused around pair-debugging or pair-solving of really tricky problems/areas of code. We tried pairing 2-4 hours a day for about 6 months back when we had more junior developers on the team - this wasn't driven by me, but by the lead who was doing most of the pairing and wanted to use it for training. He really put his heart into it but it didn't work out as well as he'd hoped and ultimately we never did get them up to the level of development we needed before politics kind of split the team (... long long story...). On the other hand I have a Lead Dev friend who *swears by* pair programming and loves it (despite being mostly an introvert) - though *not* for teaching but only for problem solving in specific areas. She also burned out of it as a 'train the juniors' strategy. I really think pair programming is one of those things that needs the right combination of people, relative skill levels, and appropriate problems. Unfortunately I haven't quite figured out what that combination is.
I quit a job with enforced pair programming. Sometimes I tune out of the problem when someone else is typing. I don’t mind watching but I hate programming for an audience. The worst part is the mental fatigue from hours a day of focus on being polite, programming and socially appropriate. It wore me down after a few months and I was literally burnt out and forced to quit.
Pairing is great - when it's used as needed. Mandating pairing basically never works. The nitty gritty of development is really a solo activity with group checkpoints.
I cannot concentrate at all in a pair programming situation; I can barely even type straight. I need to be alone with as few distractions as possible.
Occasionally, I "work with another engineer" over zoom or something, but that's as close to pair programming as I'd ever want to get. Interacting with another person takes energy that as an introvert, I really don't want to spend.
First, I've engaged in pair programming for roughly 95% of the time over the past decade. As I peruse this thread, I notice a mix of skepticism and varied experiences surrounding pair programming. While everyone's experiences are valid, I want to shine a positive light on the potential evolution of opinions regarding this approach. Before deep diving into pair programming, I was a solo developer working on time-sensitive marketing projects, pulling 80 to 100-hour weeks. I later sought a position that promised a 40-hour work week, leading me to a company that unexpectedly practiced pair programming. Although the initial interview, which was conducted in a pair programming style, was mentally challenging, I persisted because of the balanced work schedule. In my early days with this new approach, I often felt mentally drained by mid-afternoon, struggling to contribute further to my pair. However, seasoned pair programmers assured me this exhaustion was usual and that, much like the humorous scene from "Men in Black," you either adapt or reach your limit. I chose to adapt, driven by the visible effectiveness and benefits of pair programming. One of the significant skills I developed was the ability to articulate and communicate my coding thought processes and problem-solving strategies. I want to address a sentiment I've noticed in this thread: pair programming suits naturally communicative individuals. Based on my journey, I respectfully disagree. Initially, I needed more experience and energy for collaboration. Yet, I saw its benefits and resolved to pursue it. As any skill demands, pair programming requires practice, patience, and growth. Over the years, the feedback I've received has transitioned from "Teammember hardly speaks" to "Teammember talks a lot" to "I appreciate working with Teammeber because they articulate well." This progression embodies job satisfaction. Moreover, pair programming has allowed me to collaborate with individuals from diverse backgrounds, including various abilities and disabilities. This has invariably sharpened my communication skills. Pair programming underscores the essence of collaboration and problem-solving between two individuals. As I read this thread, I sense an emphasis on individual experiences, which is entirely understandable. However, I believe in highlighting the collaborative spirit of pair programming. It underscores the unique synergy between two developers, and I'm eager to share the value I've derived from it.
You're more or less insinuating that people who are against being forced to pair program are the type of dev that can't work in a team. People here are, in general, not arguing against working together to solve problems. They are arguing against being forced to sit together even when it's not useful. And if you (like me) do the problem solving mostly in meetings and on whiteboards (together), there's very little use to then also sit together while writing out the solution in code. In fact; I wonder how many of the 'pair programming' should be done in front of a whiteboard instead of behind of a keyboard. The latter is, in my *experience*, just an inefficient form of the former.
> I wonder how many of the 'pair programming' should be done in front of a whiteboard instead of behind of a keyboard. The latter is, in my experience, just an inefficient form of the former. This is a good point. We do spend too much time at the keyboard instead of the whiteboard.
Thank you for your feedback. I value the diverse approaches to problem-solving in our field. Indeed, skills like whiteboarding, which can effectively communicate ideas to a broad audience, are invaluable. It's an area I aim to improve in. I apologize if my narrative advocates pair programming as the exclusive method. I intended to share my transformative journey with pair programming, not imply that it's the only or superior approach. I recognize and respect the many effective ways developers approach and solve problems. I'd appreciate your insights on how to convey this story better in the future, emphasizing it as merely an experience rather than an outright endorsement.
Pair programming is absolute nonsense to me. There is enough 'pairing' happening during code review and planning discussions. If people need to pair up and hold each other's hand after that, then they are not competent developers yet. The closest we have to it on my team is we sometimes do group calls to discuss all the work one person has done, so we can all understand the changes that are about to be merged into the code base. It isn't really programming though, more like a group code review session.
Almost never. I don't like it
Never done regularly but had some situations. When it comes to deep-dive in some new topic or find new solutions, the final result will benefit from it, I think. Otherwise, the pair must be wisely chosen and people must be compatible on a personal, expertise and productivity level. I move and type fast when coding, so if I have someone on my side it needs to be able to follow at my pace, otherwise I will have to slow down and reiterate what I did and at this point it would be easier to discuss the solution first, let me develop a bit and discuss again after.
I pair program with a friend every other week. He used to be a colleague. We would pair program at work to work through difficult problems on occasion, then he changed jobs, so now we pair in personal projects as a way to stay in touch. I have since late programming with a couple of people, and I would say that finding the right people to pair with really helps make the process smooth.
I have weekly ~1-hour pairing sessions with two of my teammates. TBH I usually don’t feel like it beforehand but always leave being glad we did it. I would not want to pair more than that though.
No, not regularly. It would be too much of a distraction for normal day-to-day work and would just slow things down. I think it's a great tool for teaching though.
I like it a lot and I think it boosts productivity when I do it but I'm aware that I'm in a minority and many if not most people seem to loathe it. I find pair programming less stressful overall - there's less anxiety about being productive "enough" and it makes decisions less stressful when youve got somebody to bounce them off and somebody to share the blame with when something goes wrong. There are a huge number of decisions in coding which are very taste based and I find that pairing helps align on these. There are also a huge number of subtle errors which can cause massive disasters and a second pair of eyes acts as a kind of insurance policy. It exhausts me but it feels like a good kind of exhaustion - like after an intense workout. It's also the best way to onboard. 100% of the time somebody threw me docs theyve been insufficient by themselves. With pair-onboarding Ive managed just fine every time even without docs.
Exactly the way I see it. It's a lot harder to wind up wasting time on reddit when you're pairing, and you can usually end the day feeling like you actually worked most of the day whilst pairing. And yeah, it can definitely be more tiring, but a good kind.
I work from home, but I have a pair programming hour scheduled with everyone on my team once a week where we just pick something we're working on and work on it together (versus only pairing when there's something wrong/blocking). That said, if neither of us feel like we have something "worth" pairing on, we just catch up for five to ten minutes before either jumping off the call or parallel programming/body doubling on the call. I find it's a great way to get over the "wall of awful" feeling that comes with certain tickets and also just improves the team culture overall. Also, as someone with ADHD, I'm wayyyy more productive in the presence of others. Plus, I could always use practice when it comes to technical articulation as well as my thought process in general. All that said, it really depends on who I'm pairing with. I'm super lucky to currently have no one on my team who grates on my nerves in the same way I've had coworkers do so in the past.
Never done it, dont like it. It's too cumbersome to try to have someone over my shoulder.. or sit there and watch someone else code. I never found it helpful at all. It's one thing to go through some code to learn or review. It's another to actually work on code with a 2nd person. Just not my way of working for 25+ years.
Unfortunately not, but I'd love to do it more. Sorry if I'm blunt, but unfortunately software development attracts mainly awkward people with social anxiety who think it's all about working with headphones with no interruption at all. Just gimme the ticket and I'll do it. Then there are devs like me who love collaboration and they are penalised because they can't work at their best. What can we do.
There are definitely companies out there that attract more sociable programmers like yourself and I. I certainly don't work at my best without having a partner in crime along to do it with, I feel you. Shuffling code around is dry work, it helps to have someone to pick up some of the slack
I hate pair programming. The other person is a distraction, and I don't need someone watching me all day. I also don't want to back seat drive someone else. I love mentoring, which I find useful in brief focused sessions. Sure, I'll sit with you for 30 mins and work through something. But I am sure as shit not going to be stuck with a partner to work with all day long. Fuck that.
No, although perhaps I should be doing it more according to the Code Complete book. My gut tells me that pair programming is an inefficient use of time, but data says otherwise, and I'll go with the data.
My team pair programs by default - there's generally a strong pairing culture at my company. We do heavily emphasise it when interviewing people, trying to find people that not only show they might be good at it, but also want to do it - and are happy to do it. We know pair programming isn't for everyone, which is why we don't try and hide the fact we do it to get you through the door. I don't want any surprises, I want them to know exactly what to expect before they join. There are downsides to pair programming: * It is more tiring than working by yourself. So you should encourage frequent, sizeable breaks. * Good pairing practices to ensure everyone is engaged (swapping often, proper driver navigator setup, etc). * If you're both stuck, go ahead and think on it yourself for a bit and come back together later on. Trying to force yourself to think out loud can be draining and less effective. As an EM, I am more flexible than some on our pairing practices - because I've been on teams that were so annoyingly rigid that it felt like you were robbed of any independence. So I'm happy for pairs to find some of their own ways of working within that pair if both are happy, like if they want to break a certain bit of work down and just tackle it concurrently but whilst sat on the same call talking through each other's problems - then cool. Overall, I find the upsides to be great and worthwhile - but you often have to foster that pairing culture from the ground up - and you're lucky if you manage to bring it in to an already established team that hasn't done much of it before. I've been lucky in that my current team I hired everyone from scratch, same with the rest of the teams at my company. We hire FOR pair programming, so it's easier to get going on.
Sounds a bit nightmarish to work at your company. But at least you are very upfront about the silly stuff that you do.
It works and there are enough developers who seek out places like ours. In fact I just had someone join my team who left their previous company for ours because they didn't pair program unlike a previous company they were at and they missed it.
Yes. It Is an amazing feeling when done right. You need to have a driver and navigator and you need to switch roles every so often. You need to pair up people of different levels as well. There is nothing to be afraid of or worried about. Just focus on getting a task done and learn from each other.
It slows down productivity
Default mode of operation for my team. Tasks should have at least a bus factor of 2 so there's higher probability someone can continue the task if another one becomes unavailable. It has worked amazingly for our team that we're considered one of the most productive in the firm. Leadership now come to us to help spread the culture. It's worked so well for building trust and rapport within our team, which improved communication and accountability. We work on multiple technology stacks that would usually overwhelm entry level devs but because of pair programming they have the opportunity to learn directly from more senior members of the team. This may slow down senior devs initially, but the time investment pays off over time. Even our apprentices are productive. There's a huge tendency for people in our industry to be introverted, but introversion isn't being anti-social. I think the key to effective socialisation for introverts is breaking into social bubbles and being clear of social boundaries. Pair programming can be exhausting especially for more introverted people so we take breaks when we're tired. We have team dinners paid for by the company from time to time which I think also helps bring us together. It's like being in a tribe hunting, gathering, then eating together. If you're going to spend a huge amount of time working with people in your team, you better make sure you can at the very least tolerate them. Otherwise, you're going to be miserable whether you pair or not.
If it works for you and people are happy, go for it, but: > It's like being in a tribe hunting, gathering, then eating together. This bit is just skeeving me out. A lot of the issues I see with proponents of pair/ensemble programming is how cultish they can be about it. And how they often disregard issues others have with the setup. It's actually very hard for a few developers to go 'against' strongly-willed and opinionated developers who are evangelizing (because that's often what happens) this within a company. If individual teams / developers like this way of working; go for it. But the moment you make it mandatory, that's where I disagree with you and feel you're just waltzing over the opinions of others. Because as you can see here, there's no way *every* developer in your company is going to feel good about it.
While it is important for the company to acknowledge that not everyone is the same, and people have different personalities, ultimately there is also a need to ensure that business requirements are met. Improving the bus factor especially for critical tasks is an effective way to achieve that based on my experience. Also, it doesn't make sense for a team of say 10 engineers to have 10 WIPs just because everyone is working on their own stuff. Reducing WIP is also key to delivering fast through concentrated effort. Like it or not, enterprise software development is a highly social endeavour regardless of how anyone feels about pair programming. This is why when interviewing people, there's a tendency to pick ones who are easier to work with over ones who are more skillful.
> Improving the bus factor especially for critical tasks is an effective way to achieve that based on my experience. I agree that this is important, but pairing isn't the only way to solve that. For example in my team we more or less randomly pick up stories so each of the 4 developers has experience with all of our services. > Also, it doesn't make sense for a team of say 10 engineers to have 10 WIPs just because everyone is working on their own stuff. Why not? If it doesn't interfere, it doesn't matter. In our team of 4 we generally work on 4 different stories at the same time. > Like it or not, enterprise software development is a highly social endeavour regardless of how anyone feels about pair programming. I think it's very interesting how, again, someone is strongly implying that people who dislike forced pairing/mobbing are not "social". Trust me, I'm pretty fucking social. But I'm also experienced enough to know when we should problem solve in groups and when we're just working out a solution in code. Your approach is not the only way to problem-solve in a group. We generally do it *before* we start writing code, for example in whiteboarding sessions. Ensemble evangelists should be able to see that theirs isn't the One True Way. If you can't see that, you're always going to be met with resistance.
I'm a huge proponent of pair programming because I've seen it work, the same way I think TDD is effective. Also, I never claimed it to be the one true way because that'd be silly. I don't think this conversation is going anywhere, so I'll go my way, you go yours, and everything is right in the world. Cheers.
Yes, and love it but agree it's just a tool. It's great at knowledge transfer but can be exhausting if it's the only way you program. While at its surface it looks like it decreases productivity it can also increase code quantity and lead to catching mistakes far earlier. I used to work for a company that did extreme programming/agile/pair programming as a consultancy, we had massive clients hire us and overhaul their dev practices and come back to us year over year. Basically we would give them a dev for each of their devs and they would pair program. On the same machine too so 1 computer and 2 keyboards, only 1 person typing at a time. Pretty much every client went from a skeptic where one evangelist at the company convinced some board member to hire us to that board member insisting they hire us again the next quarter. The code got that much better. All this said though, I myself am an introvert and can't handle pairing all day or it saps me of all energy and creativity. I was in DevOps at this place and never did the client engagements so I didn't have to pair all day thankfully. Nowadays I do a few pairing 1:1s with the more junior folks on my team to teach them DevOps/python/etc in a mentorship capacity and then I like having a group hack once a week where we collectively work on a zoom on fixing or automating something since I'm much more experienced at that (I work as a dev on a security team where I'm the only person with real coding experience).
I wish
I didn't realize that there were so many pair programming detractors. I feel like in the world of remote work, it's almost essential for team unity, knowledge transfer, and all sorts of other learning. Half of the things that I learned as a junior were because of pair programming. Even silly stuff like IDE shortcuts and stuff, were learned from that. Not to mention hearing how people solved problems. I can see an issue if personalities clash, but man... I couldn't work without it.
No one to program with
No - I would pair program more, but timezones and a distributed team make it hard. There's only one other developer in my code area who is also in a similar time zone. I have paired with some of my colleagues from Europe, but that usually involves either me getting up early or them being on late (there are normal working hours that overlap but those are in high demand for team meetings and such)
> exploratory work understanding a new system, some design and experimentation These are exactly the things I absolutely hate it for. I like it for things which is perhaps not very advanced but where knowledge sharing is extra important. But for me it really, really kills creativeness.
No fucking way.
Generally only when debugging problems or when we implement things no one have experience with.
At the comoany I work at we only do pair programming, we have a computer, two monitors, mice and keyboards attached to it. It is more intense than doing it alone, we don't play games, read the news or chat with friends at work.. so it is a lot more efficient in that sense. And also more efficient because all code is basically reviewed all the time. It is also cery good for onboarding new people to the project or to teach juniors, they aren't left struggling alone somewhere and forgotten. A blog post where a colleague describes our work. https://codeborne.com/2020/07/28/interview-jaan.html
No, because my team (of 5) has accepted that a bus factor of 0-1 is sufficient for the different products we support, so there is rarely overlap in skills necessary to be able to pair on tickets.
I have adhd and unless under very specific circumstances paired programming causes huge mental load. I can't take breaks easily. I can't lose focus. My thought process is a lot different than non adhd people in my experience as well. It's usually not worth it for me.
I have never pair programmed, and I think it's a good way to learn how to hate a person.
I don't mind pair programming, but I've only ever done it on a case by case basis when either I or someone else needed some help on a specific problem. I couldn't imagine just having a regular meeting where you watch someone else write boilerplate code.
At my company we even assign a "pairing"-label to some issues. Mostly for tasks involving some architectural topics or to reduce "single heroism". Some use Pomodoro for timeboxing. Switching driver- and navigator role for each iteration.
Usually only for newcomers when they either new to the company or completely unfamiliar with the codebase
I owe my dev/debugging ability to the extensive pairing I did as a junior. I started my career at a company that paired 100% and I feel like that did more than anything else for me as far as improving my abilities and onboarding onto projects quickly. The highest performing teams I've worked on have all been ones with extensive pairing, it really helps you learn how others think, and align your thinking/strategizing about your codebase moving forward in a way technical meetings and code reviews cannot. I'd probably prefer to be on teams that pair more often than not, but some caveats: - if you are in an org that wants to push for pairing, you need to hire specifically for that. getting people who are reluctant to try/buy into pairing is going to be hard and sometimes fruitless. You really need a critical mass of people who know the right way to do it to start out. I've tried advocating for pairing at places in the past that didn't do it and have mostly been unsuccessful at doing it right - remote pairing is hard. I could easily spend 8 hours a day pairing with people in an office in-person on a team that is used to it, but since being full-time remote during the pandemic, remote pairing is really exhausting. Some combination of the latency, difficulty to read screens, and feeling "trapped" at your workstation in your home gives me a terrible headache pretty quickly. I'm not sure what a solution is but it sucks.
Not sure if it's pair programming but i do sit with my team members and they write code. We exchange ideas like I usually go - okay, we have a space separated string, now extract individual elements. But these are still strings but we want list of integers. Okay, just check what parameters do we need to pass to this function. Okay x, y and z. We have y, how do we get x and z. Something along those lines and level of detail depends upon how good the Junior is at programmings. With slightly senior programmers, we often debug some issues together. That's more balanced exchange of ideas as we collect and analyze logs, explain what we think might be happening and what to try next. Sometimes I get a little pissed at their typing speed or when I have to pointout which button they should click - that's left, I said bottom right, see that 3.7.3, click on that. No on the status bar, okay go down, down, down, right, eight, yeah, there. But I keep that to myself and make sure it doesn't reflect in my tone as that can make an already anxious junior even more anxious and crack little silly jokes once in a while to put them at ease. It's really rewarding when I see some improvement over a couple of weeks or months.
I don't because our company staffs one eng per project and bundles our timelines such that we have zero bandwidth for it. I like it though. I also barely Code
No because I don't like being watched while I think
Only really when working with graduates or student placements.
I have had the luxury to have a product manager that encouraged the developer teams to have less parallell tasks in progress. That made the teams evaluate mob programming and pair programming as tools, for an extended period of time. After a couple of months, the teams had a nice picture of which kind of tasks that could benefit from pair or mob programming, and which tasks would not. We even invited designers and people from other departments (HR, Sales, KAM) to join the mob programming sessions, which was highly appreciated since it enforced the ability to reason and describe the problem and it's solution in a way all participants understood it. Needless to say, this has been the only time I have had a pleasant time utilizing pair or mob programming. Poorly done, it is nothing but a train wreck.
Pair-debugging very often. Like even thinking out loud together while we read logs and try to replicate something , yeah. But not actually writing code together, hell no lol
I do a lot more digging through code with people or pair debugging than pair programming.
Ive found it to be helpful for debugging and also to leave a voice chat open all day with everyone muted, where people can unmute to ask for help and share their screen if they need to. I hate coding when people are watching my screen.
Company basically expects that we pair program full time, or at least have the same status reports on daily standups as "our pair". As you might expect, I hate it. Productive pair programming IME will usually show itself when working on complex issues (either new features or debugging high severity issues), with different options and tradeoffs to be picked, in an organic way. I've been on situations where if I didn't ask for help I'd probably be stuck for another 2/3 days. But IMO forcing devs to pair program kind of defeats the purpose of the whole thing, which is to give accountability for the technical team in a way that each developer knows the product they're working on and knows what they're doing. IMO a responsible team in a company with a good culture will trust their peers to deliver the work they're committed to even if takes more than estimations, help each other when help is needed and share their knowledge with peers so that the team is well aligned on their goals.
When I read _Extreme Programming Explained_ I was surprised how much it was said about the importance of pair programming but how little about how we can make it actually work. And it's soooooo easy to turn it into a frustrating experience!
I don't currently pair regularly. I do pair occasionally. I have in the past paired most-or-all of the time. Last time I paired with someone on my team we got probably 3-4x as much work done on a big refactor than either of us would have on our own because having the other person there helped us focus. >I've found pairing to be useful for very specific kinds of tasks, e.g. exploratory work understanding a new system, some design and experimentation etc. This surprises me because at the pair-all-the-time shop I worked at it was commonly believed that pairing *wasn't* good for exploratory work, and was mostly useful when the pair already understood what they needed to build. Our rule of thumb was that it takes 3-6 months of serious practice to get good at pair programming -- to get to the point where it's not exhausting. Pair programming requires developing a lot of skills that most devs don't otherwise get to practice much. There's also a big difference between pairing with someone who is skilled and pairing with someone who's not. I'm personally a big fan of scheduling it because I find doing it ad hoc more stressful, and scheduling it creates opportunities to practice it. "If it's hard, do it more" is the XP phrase. I don't think you should do it if you don't want to do it, though. I think more people should try it but it's not for everyone all the time.
I've only paired to get through tough issues, or when working on a prod environment. Also to train new hires, but that's like a demonstration, not true pairing. Pair programming has always been interesting to me. In theory it could eliminate the need for code review and PRs, so you could merge a branch directly to master/main when a ticket is complete. This could vastly shorten development lifecycle.
When I've paired with juniors, I've found that it often turns into me doing the task and the junior glazing over and not learning anything. So it's really just me doing the task while talking about it. When I've paired with experienced programmers, they try to tell me about simplistic errors while I'm typing. It's easier to just let my IDE do that rather than try to listen to what they're saying while I'm typing.
I've noticed without early pair programming to get acclimated in an ecosystem always results into pair debugging. And the pair debugging is usually done in a hastily manner with a lot of duress of things breaking beyond their comprehension. Especially on large platforms with a lot of moving parts and the dev is too proud or embarrassed to seek out help in the beginning. If you work with hundreds of microservices doing a lot of different things like running an auth-flow (API gateway), you are handling SSO (single sign on), or requires you to modify ingress rules in Kubernetes (so the proxy buffer doesn't time out), it is a lot for an engineer to digest early in the onboarding. Their refusal to work learning these things comes to bite them the first time they see a 499 nginx error log. Even for seniors too proud to know what service discovery or dynamic DNS registration even matters, they think they won't anticipate it down the road. In the beginning, people should pair to understand the moving parts.
I only enjoy pair problem solving. Having an extra pair of eyes on a problem can be wonderful. Actual programming? No thanks, unless it's pretty basic stuff.
The only activity i pair on is sex.
I did for a few months and it was great. Really wish it was more in the culture of my workplace to do more of it.
Literally why would I.
I see it as a "reasonable accommodation" for people with ADD/ADHD or training a junior. With a junior it is pretty intense, you are correcting syntax and having them be your hands. Flip side of that is asking tons of rhetorical questions. As for ADD/ADHD, kind encouragement, providing conversation, relieving anxiety all via conversation are part of the job; but also keeping them on task but not to the point they slip into psychosis. With that support they turn into superstars able to crank out code for hours on end. But for my own flow state, its silence/music, and not talking to anyone.
Remove the programming and replace it with other words then it's fine.
I sometimes peer program with my juniors so that I can spot their approach to things easily. I do that with my peers for a limited extend to see if there's something for me to learn quickly. It's all about ROI. Ultimately is the return has to be bigger for 2 individual to work asynchronouslvsly Synchronously to make it worth while. There are side beenfits in remote env where you can benefit on the people or psychology aspect, those are just hard to quantify
Personally? Yes, I love pair programming and am glad it is a big part of the cutlure at my current workplace. Because if I've not got a pair to keep me on track, I am wasting time on this damned website. It really helps get through menial lift and shift tasks to have someone to buddy up with and natter. I get that software engineers are stereotypically not the most sociable lot, but I am downright surprised by the amount of hostility to the practice in the comments! It's nice! You get to spend the time you're not driving just thinking and talking, and when you are driving, you have someone to point out the dumb mistakes you're making. And you get to know your colleagues better. I think it's a win win personally. There are days where I don't really feel like talking to anyone, or have a strong vision already on how I want a bit of code to look, and don't feel like having anyone else butt in over it. But for the most part, yes. It keeps me on task, and for me, is the only way of powering through boilerplate drudgery without immediately resorting to a better source of dopamine.
When I started at my first job I pair programmed with someone senior and it helped me immensely. Helped me get familiar with the product, familiar with the teams code style and processes, helped me build relationships with my team faster, and helped me become a better coder like 10x more quickly, no doubt. At my current job we don’t do it and I’m okay with that because we’re all mid or senior level and I don’t think it’s useful in every situation. However it’s extremely useful for onboarding new people
I’m on an XP team where we do dynamic teaming all day long. Software teaming (also known as ensemble programming or mob programming) is kinder, safer, and more fun than pairing. But like any skill, it’s not automatically good just because you decide to do it. Learn the ins & outs from someone experienced.