18 ms·

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total

by gleenn 5y ago

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying. Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of times faster than screwing around by yourself. Pointed-haired bosses and accountants will never understand this. If you pair and rotate, the inexperienced person becomes experienced quickly, and it's viral if you also do rotating pairing. A team with one expert and pairing is now a team full of experts.

visarga 5y ago
> People always struggle or avoid doing pair programming Would using an improved Github Copilot be similar to pair programming but without the stress? Let's assume Copilot can understand whole projects not just single files, can do proper dialogue, is able to generate test cases and explain code.
verve_rat 5y ago
In my experience a team with one expert and pairing quickly becomes a team with many so-so members and an expert facing burnout.
Veuxdo 5y ago
You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?
- rednerrus 5y ago
  It seems counterproductive to have developers on your team who aren't capable of collaborating in this way.
  - Veuxdo 5y ago
    There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".
    - erik_seaberg 5y ago
      I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?
      - _carbyau_ 5y ago
        I am not sure everyone has the same idea of pair programming. I have never done it but it simply seems like: 2 people solve a single need. How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could: Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise. Sit together hunched over a single laptop. Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat. I mean, isn't it all about simply getting along and getting a job done?
      - epolanski 5y ago
        > Do pairs agree to shut up until someone gets an idea? Hard problems are quite rare, most development is mundane. When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them. This isn
- SomeCallMeTim 5y ago
  The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers. So yes, you're correct.
  - dgb23 5y ago
    I would say that there is still a benefit of pairing an expert with a novice now and then. Not for productivity but for long term effects. They cannot be _too_ far apart though.
    - SomeCallMeTim 5y ago
      Occasional pairing, especially for knowledge transfer, is great. It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently. Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means. Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.
  - JohnKacz 5y ago
    Forgive my possible laziness in searching, but do you by chance have links to some of the studies you reference?
    - SomeCallMeTim 5y ago
      Sorry, don't have the references handy.
  - jkaptur 5y ago
    There are high-profile cases of world-class developers pairing: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
SomeCallMeTim 5y ago
That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.) On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently. Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.
- zozbot234 5y ago
  True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.
  - dboreham 5y ago
    Someone with much more experience than me once told me it always takes a year. He turned out to be right, at least over the past 25 years.
watwut 5y ago
That developer was not hitting the ground running. That developer was being carried by someone else in speed lower then that someone else normal speed. And also, pointy haired bosses and accountant don't mind pair programming all that much. Normal average developers with normal average psychology do mind it, object it, hate it.
pjmlp 5y ago
We avoid doing pair programming, because personalities matter, and this circus about driver and co-pilot is yet another "agile" marketing gimmick.
irrational 5y ago
Pair programming only works when both people have similar mental aptitudes/personalities/types/processing-speeds. The times I’ve been involved in pair programming it has been a disaster. I need time to sit there and think and process while the other person is getting bored and wants to keep going or they start to talk which ruins my thinking so I have to start over again.
stretchwithme 5y ago
I naturally prefer to do things on my own but I also find interaction with others satisfying. And I'm glad when it's over :-) In my current job, everybody is remote and you can't even play foosball with people on your team.
PragmaticPulp 5y ago
Pairing is actually great in limited scenarios where one person is an expert and the other needs to ramp up quickly from their knowledge. But at steady-state, it becomes a drain on efficiency. In my experience, forced pairing is something that a small percentage of people love but it burns most others out. Every company I've seen try to force full-time or even most-time pairing on people has quickly lost a lot of their good developers. Although on the plus side, they at least have a system in place for quickly ramping up new developers as they join to fill all of the openings.
- codr7 5y ago
  Even then, people are different. Pairing for me is good now and then, but I need time on my own in between to figure things out my way. It's like hybrid work, nice as an option. I once had a boss who tried to force me to pair program with him at his convenience to check up on me, had.
NewEntryHN 5y ago
It's developers who don't want pair programming, because they're introverted and don't like it.
kayodelycaon 5y ago
If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out. Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues. This causes me to work by feel on some tasks because I don’t work on problems in order. I visualize everything like a house of cards. I see everything at once and load random parts of what I’m looking at until I see the whole thing in my minds eye. (Because I have three logical registers on a good day.) Asking me to explain my thinking requires me to restructure the process in reverse and put it into a linear thought that can be understood by someone else. Which half the time dumps all of the registers in my short term memory. Meaning I don’t understand what I was looking at. Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly. (Good communication means better relationships with coworkers and less wasted code.) Despite the complete chaos in my brain, I write extremely good code (by other people’s measures), because I think about readability, algorithmic complexity, side effects, testability, and a thousand other minor details at the same time. Tests come in once I’m happy with the structure. (I hate working without clean understandable tests!) Then I refactor to clean up the code and comment to explain reasons why it was written specific ways, so coworkers (or future Kayodé) don’t want to murder me. If this comment is a bit rambling, you know why. :)
- Gravityloss 5y ago
  Text is linear. Would drawing be an easier method for you to explain something? It often is for me.
  - kevin_thibedeau 5y ago
    You waste your time managing visual presentation (more so than 1D text). Schematic entry used to be commonplace for FPGA and ASIC development in the 90s. The industry has mostly moved to HDLs for digital logic because it is more productive and you get side benefits like revision control, easier reusability, and tooling independence. Anyone promoting 2D visual development for programming is selling snake oil.
strken 5y ago
I like situational pair programming, but there's no point in forcing another senior developer watch me e.g. set up a toy repo to track down a bug, when we both know what error I'm currently getting and what I'll be doing. You have to be able to pair when you need it and stop pairing when you don't. For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing it.
- convolvatron 5y ago
  exactly. I find it vastly more productive to just be available at the drop of a hat to talk someone through an issue. once it gets to the point where we've decided on next steps, we can work on our own until one of us feels confused or something interesting comes up. yes - lets talk frequently about the work and what makes sense no - me watching you type and making off-the-cuff comments to keep myself busy
redisman 5y ago
I just don’t like pair programming. It feels like peer micromanagement to me. Thankfully I’ve only had to do it a few times. If we need to collaborate then let’s hit the whiteboard but please afterwards let’s work in peace on our own computers like civilized humans.
ChrisMarshallNY 5y ago
Pair programming is one answer. So is retaining engineers, so that, once they learn the system, are available to maintain/teach it, and more importantly, are invested in doing a good enough job, because they will have to be around to deal with the fallout, if it was not a good enough job. There's no one answer, but I'd suggest that having an environment that retains engineering talent, and incentivizes good, long-lasting work, could be helpful.
bufordtwain 5y ago
Maybe the sweet spot is to have someone pair with an expert when they are getting started and when they are struggling to understand things. Personally when I pair program I use a large fraction of my brain to interface with the other person. This leaves me much less brain power to work on the actual problem at hand. And it's far more exhausting to me than working alone.
ashtonkem 5y ago
The issue with pair programming has always been that some people hate it with the heat of a thousand suns. I’m one of them. Its very effective I don’t dispute that, but it makes me absolutely miserable and I’ll end up quitting to avoid doing it.
babyshake 5y ago
One side effect of pair programming frequently is it probably helps make you perform much better during job interviews with coding and system design questions.
phendrenad2 5y ago
It's hard to be scientific about this because there's no control group. If we clone your team and forbid them from using pair programming, in 5 years, which team will allow new developers to hit the ground faster? Which will have greater velocity. Which will have better code quality? Some downsides to pair programming I've noticed: 1) People can tend to jump to the first solution they find, in order to not look slow or stupid. This doesn't allow for time to refactor the solution. 2) It can promote a culture of "spoken-word documentation" where all information about the system is conveyed via word-of-mouth, and nothing is recorded. You can see how this isn't scalable... 3) Not everyone has perfect internet, desk setup, comfortable chair, microphone quality, monitor resolution, etc. and it can lead to one person mumbling and another just going "yup uh-huh yeah"
- RussianCow 5y ago
  I'll add another: you tend to miss out on some of the inner workings of the system when you have someone there to answer questions instead of diving in and figuring it out yourself. Yes, in an ideal world you have both, but doing lots of pair programming makes it too easy to take the shortcut and just ask how to do something, instead of learning the fine details of the system such that you don't have to ask those questions anymore in the future.
danielvaughn 5y ago
Onboarding buddies are the best.
uoaei 5y ago
This sounds great if you expect high employee turnover, but by that point, I'd be investigating the reasons for that rather than only addressing the symptoms.
akhmatova 5y ago
When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying. Right -- because they're not the ones actually doing the work of course. Aside form the typing "work". A team with one expert and pairing is now a team full of experts. Minus the ones who quit (or never joined) because they just can't get behind the insanity and teeth pulling that is (involuntary) PP.
epolanski 5y ago
I work in a team that leans heavily on pair programming and it's a night and day difference for productivity. Besides the domain and system knowledge sharing, besides exchanging productivity tricks or new ways to solve problems, it is much less distracting. I strongly believe that on any non-trivial task pair programming accomplishes much more business value (more tasks done) and growth than having the two developers working solo. I don't think it should be the only way to work, definitely not most of the time and it should be encouraged rather than mandated.
devoutsalsa 5y ago
> A team with one expert and pairing is now a team full of experts. I’m sorry, no. That’s not how that works.
violiner 5y ago
> a new developer could hit the ground flying. Sounds like a plane crash. :)
Havoc 5y ago
I like that description of pair programming - articulates the benefit clearly. Makes intuitive sense & haven't seen anyone explain it that clearly before. > accountants will never understand this Oh...I take it back then. I'm an accountant. Apparently I didn't understand this, so I must have been mistaken in my above assessment.
RussianCow 5y ago
> When I worked at a place that did 100% pair programming with rotation every day Putting aside whether or not it actually makes you more productive, that sounds awful to me. Part of the reason I work from home is so that I don't have to constantly interact with my peers, and can put my head down and concentrate on my work without having my train of thought constantly broken. I have no problem with pair programming as needed, but I would never work at a company that forced it all day. To each their own, though.
decebalus1 5y ago
> a place that did 100% pair programming with rotation every day Sounds like a nightmare. I interviewed once for a company where the team did exactly that, and it was the moment in the interviews I realized I don't want to work there. ad-hoc peer programming is perfectly fine. Debugging something tricky or helping someone ramp up is great. But peer programming as-a-process is literally peer-micromanaging and outright insulting IMHO.
- vidarh 5y ago
  I would break off an interview in the middle if it became clear they forced pairing.
sebringj 5y ago
That sounds effective but I wouldn't want to work there. I do pair programming but on an as-needed basis. I find it very effective in short focused bursts but I couldn't imagine doing it all day. I would go insane.
amtamt 5y ago
Things happening "always" or "never" are usually the cause of discomfort. Hard rules about 100% pair programming or opposite make things worse in long term. Starting with a "buddy" on team/ work switch almost always helps. After that, it's mostly 'it depends' thing. We must be conscious about what works best for the individuals and teams and should settle around the the sweet spot. Excess of anything is unhelpful.
treeman79 5y ago
Going on vacation was awesome. Only model I didn’t worry about anything. Some dude won the lottery / hit the bus. Minimal disruption to team. Have ADD? Well your pair keeps you on task all day, so your biggest weakness is gone and your ADD brilliance shines through. Need a few hours focus to figure out something complex. Ok this one wasn’t great.
dkersten 5y ago
I’m the type of programmer who likes to shut themselves away from the works in silence while I work. However one of the most successful complex fault tolerant distributed systems projects I ever worked on was done in a team of myself and one other guy, delivered in about 9 months from start to finish, is still, as far as I’m aware, running flawlessly years later and was developed through 100% pair programming. We did it be css use as a team of two it was important that both of us were intimately familiar with every line of code and understood every decision made, but it turned out to be an incredibly effective way of developing complex software. Some things to note: you have to get on very well with the other person, or it’s going to be frustrating. You have to have similar standards and ideals or you will clash and fight. It’s an exhausting way to work and you will need to take regular breaks. You need to be strict about the roles and about swapping roles regularly. We did a lot of remote pair programming (voice call + screen share that allows input from both: we used screenhero when it was still a thing, VSCode has shared editor support nowadays that’s not bad, not sure what other tools there are) Other people mentioned ADHD, I too have ADHD and this definitely isn’t my natural way of working. I even had some resistance to it most mornings and had to tell myself ok let’s go. And it IS exhausting, you need a lot of regular breaks, you need to be able to shut off and not think about work at all after hours or at weekends, it is a very tiring way to work. But DAMN was it effective. I don’t think we could have delivered it in 9 months, let alone without known bugs, any other way. We would not have both had the same level of understanding of the entire system.
oddthink 5y ago
I still don't really get pair programming. Maybe it's my inner introvert, but it sounds really draining. And what about all of the non-programming time during the day? I mean, today I spent time: - Digging into the analysts dashboards for some time series that seemed off. Generated a plot from my own metrics stash, filed a bug w/ the analysts about the differences. Replied to some doc comments saying that I'd done so. - Code review of a few changes. - Write a quick jupyter notebook (well, colab) analyzing a different problem. Basically reading the data for an example into the notebook, writing a bit of code to visualize it, fiddle until I had some sense of what the problem was. - Decide I should regenerate a dataset with some different processing. Spent maybe an hour doing the code changes and getting them reviewed. Then build the binary, run it to generate a dataset, then launch a few-hour processing job to see if it works better. - Write some notes on how I should decide if the new version is better than the old version. - Fire off email to a few people. Asked one person about existing viz tools, updated another about my earlier colab experiments and asking if they know of anyone who's done a similar analysis. Out of all this, I think pair programming would have maybe been tolerable for a bit in the middle when I was actually making code changes, but everything else was either based on huge amounts of internal context or was completely ephemeral analysis. I think I must be doing a different kind of thing. :-)
spywaregorilla 5y ago
Possibly dumb question, but... why do orgs need specific pair programming policies at all. Why can't you just ask questions and help each other as needed?
- borplk 5y ago
  I know I'm going to get jumped but let's be real it's a cult behaviour that originates from the cult of extreme programming ("XP"). Some of them advocate for 100% "mob programming" (3+ people working together). Doing it on a "as needed" basis is common sense and doesn't need a buzzword name either. It's what people have always been doing. But to push for 100% of it is insane and insulting to the individual.
formerkrogeremp 5y ago
From an accounting perspective,if your business isn't a SaaS or similar, why are developers anything but a cost center?
_huayra_ 5y ago
Having been on both the knowledgeable and noob side of this "pair programming onboarding", I find it to be fantastic. When furiously googling / grepping around the code to self-onboard, it is so difficult to see the bigger picture of how the system works; if someone can explain the architecture to you, you become much more self sufficient, very quickly too. On the "mentor" side of such pair programming, it is extremely useful to have to verbalize things that you may have gotten away with only fuzzy knowledge of previously. When the new hire asks a question that makes you say "oh wow that actually is quite broken!", you win as well!
- redisman 5y ago
  > if someone can explain the architecture to you This should happen anyway - pairing or no. What kind of onboarding are people doing where architecture overview isn’t a part of it?
  - irishsultan 5y ago
    Explaining the architecture in the abstract and explaining the architecture while changing something to the application are very different things. Both for the explainer and for the person trying to understand and process the explanation.
eek2121 5y ago
We do pair programming. The issue is that all of the developers that knew our system left a long time ago. NOTE: this next part applies to the US. Why? Developer salaries went vertical when COVID hit. All those Silicon Valley jobs became remote with big fat salaries and companies took months to respond, and many did not respond at all. The job I started last year I would have left if it weren't for the fact that I work well under 40 hours for a 6-figure salary. If you are getting paid less than 100k/year with at least 3 years of experience, find a new job. Don't treat your job like it is your life. It isn't. They would fire you if they knew they could have someone do your work for half the cost, so don't let them "use you against you".
shakaijin 5y ago
My god, I am in the position right now where I basically have to screw around by myself in order to figure the system out. It is hell....
throwaway54976 5y ago
As an IC I had spend so much effort in knowing the system. My pointed hairy boss has to know how hard it is to know my value. The only way he knows is to compare with others who take similar or longer time to implement similar feature. With pair programming I will speed up my coworkers at the cost of my pointed hairy boss thinking my job is easier and I am the one who is less capable.
mihaaly 5y ago
It sounds like a small project where everything can be remembered by everyone uniformly and perfectly and also people with specialty and exceptional talent into one or the other area are laid off, and everyone is uniform in level of capabilities and preferred area of activity (so it doesn't matter who sits with who over what). Sounds too idealistic where it never happens that two come together who are equally weak or even clueless of a big legacy code and it never happens that the session becomes a guessing game. : ) Pair programming is fine in learning but the team of uniform level experts is too much of a fairytale idea to me for a generally useful concept in the complexity of life (and projects). Don't blame the pointed-haired bosses and accountants alone if the variety of workforce and projects, life itself (differences, variations, uncertainties, logistics, economics, ...), speak against the precious pair programming here and there and it will never be a 100% soluion for everyone and everything. Except if you eliminate/refuse situations with opposing aspects rigorously and without mercy of course.
thesz 5y ago
No, you won't "get to speed million times faster" by getting answers immediately. You have to learn system before you can ask sufficiently important questions. I recently learned that some database system, internally, always performs two operations in the specific consecutive order. It was quite critical for my task at hand and no-one on the team was able to answer this precise question about the order, including team leader with deep historic knowledge. I had to read code, I had to prove that this sequence will be exactly as I need in cases that are important for me. And I read and reread the code before that "proof process" even to get the understanding that I can implement my solution if I can guarantee that order somehow. "All easy problems are already solved", if I may quote fortune program. The hard problems take time for research. By doing that research yourself, you learn how to do research, you learn code better and, finally, you are not doing research with someone who, well, may not know solution for your problem and may not even have a clue on what may help you with the solution. The last point means that you are not wasting someone's time and you are not wasting your time too. You say "A team with one expert and pairing is now a team full of experts" and I cannot agree with that for any problem domain that requires any kind of research.
vidarh 5y ago
And you select away anyone who does best in different environments, or who refuse to entertain working for you because of the enforced pairing. Personally I can think of few things more exhausting and detrimental to my wellbeing than suffering through pair programming. You can get most of the benefits just fine without it, with occasional sessions, without the cost of driving away people.
Enhex 5y ago
writing documentation is even better, only have to explain something once.
toomanybeersies 5y ago
I wouldn't call pairing up with a new hire "pair programming" in the strict sense of the term. That's just regular onboarding/mentorship.
stuckinhell 5y ago
I've done pair programming as the senior developer often at a previous job. It sucked. I paired with a young woman fresh out of a boot camp, and at first I was excited to do it because it was nice to have another woman developer. Yet she was just so threatened by me or insecure about her experience, she started gossip about me. Just awful Another time it was with a mid level middle aged man, he just had a huge ego and felt the need to question single thing I did. Honestly the best pair programming experience I had was with a "sports bro" type. I always wonder if it was due to fact coaches are a big deal in sports. I refuse to do pair programming these days if I can avoid it.
z3ncyberpunk 5y ago
What you describe is just showing someone the ropes, not pair programming at all
bezospen15 5y ago
Haired programming is bogus. It's just another form of micromanagement invented by MBA types. They're constantly trying to make us more productive and forcing us to collaborate in uncomfortable ways. Our jobs are difficult, it should be done at our pace, not theirs
bezospen15 5y ago
Paired programming is bogus. It is enforced by MBA types that are trying to get every last ounce of productivity out of us and forces you into uncomfortable collaboration scenarios. Our jobs are extremely difficult. It should be done at our pace in our environment, not theirs

by gleenn 5y ago

visarga 5y ago

> People always struggle or avoid doing pair programming Would using an improved Github Copilot be similar to pair programming but without the stress? Let's assume Copilot can understand whole projects not just single files, can do proper dialogue, is able to generate test cases and explain code.

verve_rat 5y ago

In my experience a team with one expert and pairing quickly becomes a team with many so-so members and an expert facing burnout.

Veuxdo 5y ago

You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?

rednerrus 5y ago
It seems counterproductive to have developers on your team who aren't capable of collaborating in this way.
- Veuxdo 5y ago
  There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".
  - erik_seaberg 5y ago
    I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?
    - _carbyau_ 5y ago
      I am not sure everyone has the same idea of pair programming. I have never done it but it simply seems like: 2 people solve a single need. How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could: Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise. Sit together hunched over a single laptop. Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat. I mean, isn't it all about simply getting along and getting a job done?
    - epolanski 5y ago
      > Do pairs agree to shut up until someone gets an idea? Hard problems are quite rare, most development is mundane. When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them. This isn
SomeCallMeTim 5y ago
The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers. So yes, you're correct.
- dgb23 5y ago
  I would say that there is still a benefit of pairing an expert with a novice now and then. Not for productivity but for long term effects. They cannot be _too_ far apart though.
  - SomeCallMeTim 5y ago
    Occasional pairing, especially for knowledge transfer, is great. It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently. Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means. Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.
- JohnKacz 5y ago
  Forgive my possible laziness in searching, but do you by chance have links to some of the studies you reference?
  - SomeCallMeTim 5y ago
    Sorry, don't have the references handy.
- jkaptur 5y ago
  There are high-profile cases of world-class developers pairing: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...

SomeCallMeTim 5y ago

That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.) On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently. Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.

zozbot234 5y ago
True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.
- dboreham 5y ago
  Someone with much more experience than me once told me it always takes a year. He turned out to be right, at least over the past 25 years.

watwut 5y ago

That developer was not hitting the ground running. That developer was being carried by someone else in speed lower then that someone else normal speed. And also, pointy haired bosses and accountant don't mind pair programming all that much. Normal average developers with normal average psychology do mind it, object it, hate it.

pjmlp 5y ago

We avoid doing pair programming, because personalities matter, and this circus about driver and co-pilot is yet another "agile" marketing gimmick.

irrational 5y ago

Pair programming only works when both people have similar mental aptitudes/personalities/types/processing-speeds. The times I’ve been involved in pair programming it has been a disaster. I need time to sit there and think and process while the other person is getting bored and wants to keep going or they start to talk which ruins my thinking so I have to start over again.

stretchwithme 5y ago

I naturally prefer to do things on my own but I also find interaction with others satisfying. And I'm glad when it's over :-) In my current job, everybody is remote and you can't even play foosball with people on your team.

PragmaticPulp 5y ago

Pairing is actually great in limited scenarios where one person is an expert and the other needs to ramp up quickly from their knowledge. But at steady-state, it becomes a drain on efficiency. In my experience, forced pairing is something that a small percentage of people love but it burns most others out. Every company I've seen try to force full-time or even most-time pairing on people has quickly lost a lot of their good developers. Although on the plus side, they at least have a system in place for quickly ramping up new developers as they join to fill all of the openings.

codr7 5y ago
Even then, people are different. Pairing for me is good now and then, but I need time on my own in between to figure things out my way. It's like hybrid work, nice as an option. I once had a boss who tried to force me to pair program with him at his convenience to check up on me, had.

NewEntryHN 5y ago

It's developers who don't want pair programming, because they're introverted and don't like it.

kayodelycaon 5y ago

If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out. Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues. This causes me to work by feel on some tasks because I don’t work on problems in order. I visualize everything like a house of cards. I see everything at once and load random parts of what I’m looking at until I see the whole thing in my minds eye. (Because I have three logical registers on a good day.) Asking me to explain my thinking requires me to restructure the process in reverse and put it into a linear thought that can be understood by someone else. Which half the time dumps all of the registers in my short term memory. Meaning I don’t understand what I was looking at. Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly. (Good communication means better relationships with coworkers and less wasted code.) Despite the complete chaos in my brain, I write extremely good code (by other people’s measures), because I think about readability, algorithmic complexity, side effects, testability, and a thousand other minor details at the same time. Tests come in once I’m happy with the structure. (I hate working without clean understandable tests!) Then I refactor to clean up the code and comment to explain reasons why it was written specific ways, so coworkers (or future Kayodé) don’t want to murder me. If this comment is a bit rambling, you know why. :)

Gravityloss 5y ago
Text is linear. Would drawing be an easier method for you to explain something? It often is for me.
- kevin_thibedeau 5y ago
  You waste your time managing visual presentation (more so than 1D text). Schematic entry used to be commonplace for FPGA and ASIC development in the 90s. The industry has mostly moved to HDLs for digital logic because it is more productive and you get side benefits like revision control, easier reusability, and tooling independence. Anyone promoting 2D visual development for programming is selling snake oil.

strken 5y ago

I like situational pair programming, but there's no point in forcing another senior developer watch me e.g. set up a toy repo to track down a bug, when we both know what error I'm currently getting and what I'll be doing. You have to be able to pair when you need it and stop pairing when you don't. For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing it.

convolvatron 5y ago
exactly. I find it vastly more productive to just be available at the drop of a hat to talk someone through an issue. once it gets to the point where we've decided on next steps, we can work on our own until one of us feels confused or something interesting comes up. yes - lets talk frequently about the work and what makes sense no - me watching you type and making off-the-cuff comments to keep myself busy

redisman 5y ago

I just don’t like pair programming. It feels like peer micromanagement to me. Thankfully I’ve only had to do it a few times. If we need to collaborate then let’s hit the whiteboard but please afterwards let’s work in peace on our own computers like civilized humans.

ChrisMarshallNY 5y ago

Pair programming is one answer. So is retaining engineers, so that, once they learn the system, are available to maintain/teach it, and more importantly, are invested in doing a good enough job, because they will have to be around to deal with the fallout, if it was not a good enough job. There's no one answer, but I'd suggest that having an environment that retains engineering talent, and incentivizes good, long-lasting work, could be helpful.

bufordtwain 5y ago

Maybe the sweet spot is to have someone pair with an expert when they are getting started and when they are struggling to understand things. Personally when I pair program I use a large fraction of my brain to interface with the other person. This leaves me much less brain power to work on the actual problem at hand. And it's far more exhausting to me than working alone.

ashtonkem 5y ago

The issue with pair programming has always been that some people hate it with the heat of a thousand suns. I’m one of them. Its very effective I don’t dispute that, but it makes me absolutely miserable and I’ll end up quitting to avoid doing it.

babyshake 5y ago

One side effect of pair programming frequently is it probably helps make you perform much better during job interviews with coding and system design questions.

phendrenad2 5y ago

It's hard to be scientific about this because there's no control group. If we clone your team and forbid them from using pair programming, in 5 years, which team will allow new developers to hit the ground faster? Which will have greater velocity. Which will have better code quality? Some downsides to pair programming I've noticed: 1) People can tend to jump to the first solution they find, in order to not look slow or stupid. This doesn't allow for time to refactor the solution. 2) It can promote a culture of "spoken-word documentation" where all information about the system is conveyed via word-of-mouth, and nothing is recorded. You can see how this isn't scalable... 3) Not everyone has perfect internet, desk setup, comfortable chair, microphone quality, monitor resolution, etc. and it can lead to one person mumbling and another just going "yup uh-huh yeah"

RussianCow 5y ago
I'll add another: you tend to miss out on some of the inner workings of the system when you have someone there to answer questions instead of diving in and figuring it out yourself. Yes, in an ideal world you have both, but doing lots of pair programming makes it too easy to take the shortcut and just ask how to do something, instead of learning the fine details of the system such that you don't have to ask those questions anymore in the future.

danielvaughn 5y ago

Onboarding buddies are the best.

uoaei 5y ago

This sounds great if you expect high employee turnover, but by that point, I'd be investigating the reasons for that rather than only addressing the symptoms.

akhmatova 5y ago

When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying. Right -- because they're not the ones actually doing the work of course. Aside form the typing "work". A team with one expert and pairing is now a team full of experts. Minus the ones who quit (or never joined) because they just can't get behind the insanity and teeth pulling that is (involuntary) PP.

epolanski 5y ago

I work in a team that leans heavily on pair programming and it's a night and day difference for productivity. Besides the domain and system knowledge sharing, besides exchanging productivity tricks or new ways to solve problems, it is much less distracting. I strongly believe that on any non-trivial task pair programming accomplishes much more business value (more tasks done) and growth than having the two developers working solo. I don't think it should be the only way to work, definitely not most of the time and it should be encouraged rather than mandated.

devoutsalsa 5y ago

> A team with one expert and pairing is now a team full of experts. I’m sorry, no. That’s not how that works.

violiner 5y ago

> a new developer could hit the ground flying. Sounds like a plane crash. :)

Havoc 5y ago

I like that description of pair programming - articulates the benefit clearly. Makes intuitive sense & haven't seen anyone explain it that clearly before. > accountants will never understand this Oh...I take it back then. I'm an accountant. Apparently I didn't understand this, so I must have been mistaken in my above assessment.

RussianCow 5y ago

> When I worked at a place that did 100% pair programming with rotation every day Putting aside whether or not it actually makes you more productive, that sounds awful to me. Part of the reason I work from home is so that I don't have to constantly interact with my peers, and can put my head down and concentrate on my work without having my train of thought constantly broken. I have no problem with pair programming as needed, but I would never work at a company that forced it all day. To each their own, though.

decebalus1 5y ago

> a place that did 100% pair programming with rotation every day Sounds like a nightmare. I interviewed once for a company where the team did exactly that, and it was the moment in the interviews I realized I don't want to work there. ad-hoc peer programming is perfectly fine. Debugging something tricky or helping someone ramp up is great. But peer programming as-a-process is literally peer-micromanaging and outright insulting IMHO.

vidarh 5y ago
I would break off an interview in the middle if it became clear they forced pairing.

sebringj 5y ago

That sounds effective but I wouldn't want to work there. I do pair programming but on an as-needed basis. I find it very effective in short focused bursts but I couldn't imagine doing it all day. I would go insane.

amtamt 5y ago

Things happening "always" or "never" are usually the cause of discomfort. Hard rules about 100% pair programming or opposite make things worse in long term. Starting with a "buddy" on team/ work switch almost always helps. After that, it's mostly 'it depends' thing. We must be conscious about what works best for the individuals and teams and should settle around the the sweet spot. Excess of anything is unhelpful.

treeman79 5y ago

Going on vacation was awesome. Only model I didn’t worry about anything. Some dude won the lottery / hit the bus. Minimal disruption to team. Have ADD? Well your pair keeps you on task all day, so your biggest weakness is gone and your ADD brilliance shines through. Need a few hours focus to figure out something complex. Ok this one wasn’t great.

dkersten 5y ago

I’m the type of programmer who likes to shut themselves away from the works in silence while I work. However one of the most successful complex fault tolerant distributed systems projects I ever worked on was done in a team of myself and one other guy, delivered in about 9 months from start to finish, is still, as far as I’m aware, running flawlessly years later and was developed through 100% pair programming. We did it be css use as a team of two it was important that both of us were intimately familiar with every line of code and understood every decision made, but it turned out to be an incredibly effective way of developing complex software. Some things to note: you have to get on very well with the other person, or it’s going to be frustrating. You have to have similar standards and ideals or you will clash and fight. It’s an exhausting way to work and you will need to take regular breaks. You need to be strict about the roles and about swapping roles regularly. We did a lot of remote pair programming (voice call + screen share that allows input from both: we used screenhero when it was still a thing, VSCode has shared editor support nowadays that’s not bad, not sure what other tools there are) Other people mentioned ADHD, I too have ADHD and this definitely isn’t my natural way of working. I even had some resistance to it most mornings and had to tell myself ok let’s go. And it IS exhausting, you need a lot of regular breaks, you need to be able to shut off and not think about work at all after hours or at weekends, it is a very tiring way to work. But DAMN was it effective. I don’t think we could have delivered it in 9 months, let alone without known bugs, any other way. We would not have both had the same level of understanding of the entire system.

oddthink 5y ago

I still don't really get pair programming. Maybe it's my inner introvert, but it sounds really draining. And what about all of the non-programming time during the day? I mean, today I spent time: - Digging into the analysts dashboards for some time series that seemed off. Generated a plot from my own metrics stash, filed a bug w/ the analysts about the differences. Replied to some doc comments saying that I'd done so. - Code review of a few changes. - Write a quick jupyter notebook (well, colab) analyzing a different problem. Basically reading the data for an example into the notebook, writing a bit of code to visualize it, fiddle until I had some sense of what the problem was. - Decide I should regenerate a dataset with some different processing. Spent maybe an hour doing the code changes and getting them reviewed. Then build the binary, run it to generate a dataset, then launch a few-hour processing job to see if it works better. - Write some notes on how I should decide if the new version is better than the old version. - Fire off email to a few people. Asked one person about existing viz tools, updated another about my earlier colab experiments and asking if they know of anyone who's done a similar analysis. Out of all this, I think pair programming would have maybe been tolerable for a bit in the middle when I was actually making code changes, but everything else was either based on huge amounts of internal context or was completely ephemeral analysis. I think I must be doing a different kind of thing. :-)

spywaregorilla 5y ago

Possibly dumb question, but... why do orgs need specific pair programming policies at all. Why can't you just ask questions and help each other as needed?

borplk 5y ago
I know I'm going to get jumped but let's be real it's a cult behaviour that originates from the cult of extreme programming ("XP"). Some of them advocate for 100% "mob programming" (3+ people working together). Doing it on a "as needed" basis is common sense and doesn't need a buzzword name either. It's what people have always been doing. But to push for 100% of it is insane and insulting to the individual.

formerkrogeremp 5y ago

From an accounting perspective,if your business isn't a SaaS or similar, why are developers anything but a cost center?

_huayra_ 5y ago

Having been on both the knowledgeable and noob side of this "pair programming onboarding", I find it to be fantastic. When furiously googling / grepping around the code to self-onboard, it is so difficult to see the bigger picture of how the system works; if someone can explain the architecture to you, you become much more self sufficient, very quickly too. On the "mentor" side of such pair programming, it is extremely useful to have to verbalize things that you may have gotten away with only fuzzy knowledge of previously. When the new hire asks a question that makes you say "oh wow that actually is quite broken!", you win as well!

redisman 5y ago
> if someone can explain the architecture to you This should happen anyway - pairing or no. What kind of onboarding are people doing where architecture overview isn’t a part of it?
- irishsultan 5y ago
  Explaining the architecture in the abstract and explaining the architecture while changing something to the application are very different things. Both for the explainer and for the person trying to understand and process the explanation.

eek2121 5y ago

We do pair programming. The issue is that all of the developers that knew our system left a long time ago. NOTE: this next part applies to the US. Why? Developer salaries went vertical when COVID hit. All those Silicon Valley jobs became remote with big fat salaries and companies took months to respond, and many did not respond at all. The job I started last year I would have left if it weren't for the fact that I work well under 40 hours for a 6-figure salary. If you are getting paid less than 100k/year with at least 3 years of experience, find a new job. Don't treat your job like it is your life. It isn't. They would fire you if they knew they could have someone do your work for half the cost, so don't let them "use you against you".

shakaijin 5y ago

My god, I am in the position right now where I basically have to screw around by myself in order to figure the system out. It is hell....

throwaway54976 5y ago

As an IC I had spend so much effort in knowing the system. My pointed hairy boss has to know how hard it is to know my value. The only way he knows is to compare with others who take similar or longer time to implement similar feature. With pair programming I will speed up my coworkers at the cost of my pointed hairy boss thinking my job is easier and I am the one who is less capable.

mihaaly 5y ago

It sounds like a small project where everything can be remembered by everyone uniformly and perfectly and also people with specialty and exceptional talent into one or the other area are laid off, and everyone is uniform in level of capabilities and preferred area of activity (so it doesn't matter who sits with who over what). Sounds too idealistic where it never happens that two come together who are equally weak or even clueless of a big legacy code and it never happens that the session becomes a guessing game. : ) Pair programming is fine in learning but the team of uniform level experts is too much of a fairytale idea to me for a generally useful concept in the complexity of life (and projects). Don't blame the pointed-haired bosses and accountants alone if the variety of workforce and projects, life itself (differences, variations, uncertainties, logistics, economics, ...), speak against the precious pair programming here and there and it will never be a 100% soluion for everyone and everything. Except if you eliminate/refuse situations with opposing aspects rigorously and without mercy of course.

thesz 5y ago

No, you won't "get to speed million times faster" by getting answers immediately. You have to learn system before you can ask sufficiently important questions. I recently learned that some database system, internally, always performs two operations in the specific consecutive order. It was quite critical for my task at hand and no-one on the team was able to answer this precise question about the order, including team leader with deep historic knowledge. I had to read code, I had to prove that this sequence will be exactly as I need in cases that are important for me. And I read and reread the code before that "proof process" even to get the understanding that I can implement my solution if I can guarantee that order somehow. "All easy problems are already solved", if I may quote fortune program. The hard problems take time for research. By doing that research yourself, you learn how to do research, you learn code better and, finally, you are not doing research with someone who, well, may not know solution for your problem and may not even have a clue on what may help you with the solution. The last point means that you are not wasting someone's time and you are not wasting your time too. You say "A team with one expert and pairing is now a team full of experts" and I cannot agree with that for any problem domain that requires any kind of research.

vidarh 5y ago

And you select away anyone who does best in different environments, or who refuse to entertain working for you because of the enforced pairing. Personally I can think of few things more exhausting and detrimental to my wellbeing than suffering through pair programming. You can get most of the benefits just fine without it, with occasional sessions, without the cost of driving away people.

Enhex 5y ago

writing documentation is even better, only have to explain something once.

toomanybeersies 5y ago

I wouldn't call pairing up with a new hire "pair programming" in the strict sense of the term. That's just regular onboarding/mentorship.

stuckinhell 5y ago

I've done pair programming as the senior developer often at a previous job. It sucked. I paired with a young woman fresh out of a boot camp, and at first I was excited to do it because it was nice to have another woman developer. Yet she was just so threatened by me or insecure about her experience, she started gossip about me. Just awful Another time it was with a mid level middle aged man, he just had a huge ego and felt the need to question single thing I did. Honestly the best pair programming experience I had was with a "sports bro" type. I always wonder if it was due to fact coaches are a big deal in sports. I refuse to do pair programming these days if I can avoid it.

z3ncyberpunk 5y ago

What you describe is just showing someone the ropes, not pair programming at all

bezospen15 5y ago

Haired programming is bogus. It's just another form of micromanagement invented by MBA types. They're constantly trying to make us more productive and forcing us to collaborate in uncomfortable ways. Our jobs are difficult, it should be done at our pace, not theirs

bezospen15 5y ago

Paired programming is bogus. It is enforced by MBA types that are trying to get every last ounce of productivity out of us and forces you into uncomfortable collaboration scenarios. Our jobs are extremely difficult. It should be done at our pace in our environment, not theirs