13 ms·

Pair Programming Antipatterns

247 points by _ttg 5y ago

thrower123 5y ago
Forced pair programming is an antipattern. It's a recipe for burning your best workers. You had better hope that the oft-touted knowledge transfer benefits of pairing are real, because you are going to have to deal with the turnover.
- ParetoOptimal 5y ago
  > Forced pair programming is an antipattern. It's a recipe for burning your best workers. I won't say I totally disagree, but what are your reasons for thinking this?
number6 5y ago
Using two input devices on one PC never occurred to me. Is it just plug and play or does it require some setup ?
- Aeolun 5y ago
  Based on my connecting multiple boards, I think it’s plug and play. The hard part is if you want to distinguish between what board a keystroke came from.
- deleted 5y ago
  [deleted]
- samatman 5y ago
  Users of laptops routinely plug a mouse and keyboard in, while the original trackpad and keyboard continue to work. We don't think anything of it. It's the same thing with two 'exterior' keyboards and mice.
  - number6 5y ago
    Mindblown... I do this all the time... wow never thought about sharing a keyboard with somebody else. Blindspot.
- namibj 5y ago
  Technically it works directly, but with e.g. multi-pointer X you can bind HIDs to a pointer (aka cursor), and control them independently and concurrently as long as you don't confuse the applications you're interacting with. I think Emacs is tolerant in that respect, but beyond that, some trickery is likely required to make this work (i.e., multiple browser instances).
scanr 5y ago
We tried out Live Share (collaborative editing) during pair and mob programming sessions. I enjoyed it a lot - made it feel like a multi-player game. Sometimes it did allow for the equivalent of a pair programmer taking over the keyboard rather than explaining how to solve a problem. I’m curious if anyone has any Live Share patterns / anti-patterns.
- jeppester 5y ago
  We use live share a lot for pair programming. It works okayish, but the built-in terminal is borderline useless for guests due to its very poor handling of different view port sizes. I recommend to instead let your pair in through SSH (a reverse proxy, like ngrok, is useful), and then sharing a tmux session.
- mlloydw 5y ago
  I used to do a fair amount over LiveShare and we would adapt depending on the relationship we had. It got more interesting the more level we were. One of the more successful patterns that came out was to: talk about the goal, write out the code that acted as interfaces between the two of us, and then split up and tackle two things at once. That might have been code vs tests, backend vs frontend, migration vs adapting existing code. We would often then swap and discuss what we'd done (and we might be asking little questions as we go to help refine each other's approach), add improvements or plug gaps and then finally give it a good end-to-end run through with some exploration. We were working together on the problem, asynchronously, and you'd be surprised how little there were occasions where a big assumption at the beginning was missed and made us go off in different directions. This was nearly always caught early as we talked whilst we worked on our separate areas and had a quick glance at what the other person was writing. I'm convinced that we caught them faster than if I was alone as we had the opportunity to think about the problem from multiple perspectives at once.
pooya72 5y ago
I've never pair programmed before, so if anyone has any advice like this that they're willing to share it would be helpful.
- BoardsOfCanada 5y ago
  As someone who has programmed for a very long time but only done pair-programming a lot last few years, the big things in my opinion is: - If you're the driver (handles the typing), don't allow yourself to be stressed and just type things someone else tells you to type. - Language is really bad at comunicating where to make a change on a gigantic screen of text, expect yourself and others to become a bit frustrated at times, but it's at the difficulty of communicating things, not that the other person is dumb. "And change the type to bool. No not that one. Go to the end of the line, then back to the last bracket. No, the line you were at. Yes. Now go to the last bracket. Change to bool." And then take a second to understand why, asking if necessary, becuase it might get more difficult to understand later. - It's extremely difficult not to get lost when someone else is navigating between tabs, especially if you don't know the code well (and sometimes even if you do).
  - tialaramex 5y ago
    I would guess that Keep Talking And Nobody Explodes would be a good exercise to learn what the problem is without getting into domain specific skills. https://keeptalkinggame.com/ https://keeptalkinggame.com/ (ideally play this with the defusal in VR) KTANE even has (to a greater extent, and for humour) the ambiguities that can trouble talking to somebody about programming, like offering "YES", "AND", "&" and "NO" as options somebody needs to pick quickly.
  - pooya72 5y ago
    That's helpful, thanks!
- travisjungroth 5y ago
  http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong... Pair programming is terrible by default. You have to work to make it good, but then it can be great.
gregkerzhner 5y ago
Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it. I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later. Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!
- slaymaker1907 5y ago
  You missed what I consider to be the greatest strength of pair programming: debugging. If one person gets stuck on something, the other person often still has some ideas on how to proceed. Even if you don't pair program, you absolutely should be debugging with someone else if possible.
- jordanbeiber 5y ago
  In, for example, an enterprise setting you rarely want individually clever and creative solutions. You generally want domain expertise shared in a team, and continuously molded to perfection over time. Mobs and pairs can really shine here, but it all depends on the individuals. In teams where it works well it’s an enormous value add, in my experience, and the hive mind you reach after a year or two within a team is fantastic. As a dev manager I let the teams decide, but looking at team flow over time, it looks hard to beat a well functioning pair or mob team. IMHO & YMMV, and so on.
- epolanski 5y ago
  I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons: - knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context - focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck. cons: - you are blocked from working if a coworkers schedule is not aligned Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.
skeletal88 5y ago
I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair. Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs. Pairing works for us because it's more efficient than working alone, less bugs and better thought out design, faster spread of knowledge about our tools and the project in general. I joined a year ago and hadn't used Java or IDEA, pairing helped me learn all of it very fast, compared to if I had to work alone and struggle with learning all of the new things.
- meken 5y ago
  Which company do you work for? I researched pair programming companies a while back and didn’t find any.
  - calderwoodra 5y ago
    Large consultancy, pair programs all the time, Java... I would guess Pivotal
    - DLion 5y ago
      Pivotal doesn't exist anymore. It has been acquired by Vmware and now it calls Tanzu Labs: https://tanzu.vmware.com/labs https://tanzu.vmware.com/labs Btw there are many other companies where you can pair: Thoughtworks and Codurance for example
  - skeletal88 5y ago
    Not Pivotal or a large consultancy, I'm from Estonia but the company is Codeborne - www.codeborne.com they have been doing it for 12 years soon.
  - deleted 5y ago
    [deleted]
  - epgui 5y ago
    CircleCI does a lot of pairing.
samuelfekete 5y ago
> Sit so that the monitor is between the two of you. No. Use two monitors that are mirrored or with screen sharing, so that each person can sit comfortably centred on their own screen.
- lvspiff 5y ago
  Take that one step better and each should have their own resolution. Just cause your 20 yr old eyes looking at a 4k super widescreen monitor can read it doesn't mean my 30 yr old eyes with glasses on a laptop can read it too (I really like code with me on Pycharm)
- brrrrrm 5y ago
  I've found shared tmux/screen sessions are ideal. + each person can have their own font/resolution + it doesn't dominate the entire screen, allowing each person to keep their own notes/etc on the side + at any point someone can "jump in" and take control of the session + interacting in a confined shared space radically reduces "over communication" issues. i.e. if you want to show something it's got to be demonstrable in a small textual window + you have a shared command-line, which is more useful than it might initially seem + seamlessly scales to in-person and remote pair programming There are some downsides: - it requires both users are familiar with a terminal based editor - it may present security issues for folks operating in locked-down/low-resource environments (e.g. can't spin up a temporary machine with a shared account) - sharing graphical information requires a separate communication layer
  - reidrac 5y ago
    Even considering how easy things are using tmate, it is really challenging because there are a lot of Software Engineers that don't really know how to use a terminal to the point that asking to do a SSH is a bit too much. So we end sharing the screen over hang outs, that is basically very inefficient and wastes a lot of CPU. But because it is normalized, it is "the standard". EDIT: my comment was a bit unfair. I guess I could install VS Code, change my daily editor, and use it with the Live Share plugin with those using VS Code. So hang outs it is.
donw 5y ago
The entire guide just worth a read, even if you’re an experienced pair. Lots of great patterns. We do full-time pair programming in my teams, and this guide is part of our “starter pack” for documentation.
- reflexco 5y ago
  Great resource I agree. The guide is concise and could seem obvious to many peeps, but it made me reflect about my own pair programming sessions and notice I likely failed at a bunch of those points.
  - donw 5y ago
    The same. I've been pairing for probably close to a decade now, and this guide helped me to reflect on my own style, and gave me a few points to refine as well. As an aside, one of the things I make sure to do with new hires is to cover "beginner's mind". Just because you've got ten years on the iron doesn't mean you can't learn something new, and that something new might just be from the grass-green new guy that joined last week. Likewise, for the new guys that think they're hot shit because they've got a degree from McSmartypants University doesn't mean you actually know anything. Don't just take things on an "I said so" basis, but also don't discount the value of experience. When you run into a new idea: use active listening to ensure you understand it, and explore its ramifications. Poke and see where it falls down, and where it doesn't. You'll avoid a lot of bullshit this way.
nmisko 5y ago
I'd be interested in such a write up for remote pair programming. Being remote the likelihood is much higher that the navigator loses focus and answers emails or slack instead. Switching roles more quickly might be the solution. We've tried tools like mob.sh, but the most efficient way seems to be using something like VSCodes liveshare. Unfortunately half of my team uses Intellij and the other half VSCode.
deleted 5y ago
[deleted]
codeflo 5y ago
“Allowing unproductive distractions” is one of the major reason why I think home office is fundamentally less productive, no matter how much people have come to like it. Pair programming through screen sharing works fine on a technical level, but you can’t turn off children.
- vidarh 5y ago
  You can't turn off disruptive co-workers either. When I used to go in to an office of sorts one day a week, I eventually wrote that day off and just accepted that day was for socialising and design meetings. Throughput consistently tanked on those days, so better to accept it and use it for activities that didn't require the same mental focus.
- davidmurdoch 5y ago
  '“Allowing unproductive distractions” is one of the major reason why I think going in to the office is fundamentally less productive, no matter how much people have come to like it. Pair programming on-site works fine on a technical level, but you can’t turn off co-workers or your managers.' FTFY
- Icathian 5y ago
  If you don't have someone else watching your children while you work, you're probably not going to have a good time working remote regardless of coding style. Most of us working from home have addressed childcare and aren't just leaving food and water bowls out while they run around doing as they please...
Abroszka 5y ago
I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful. Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.
- Icathian 5y ago
  Having larger groups collaborate like that is called "mob programming". I'm not sure how popular it actually is but I see it talked about on HN and Reddit all the time.
  - MattGaiser 5y ago
    I have a friend currently doing it. It just lets him work on his masters degree all day.
Mountain_Skies 5y ago
I've done plenty of pair programming informally when one of us were stuck on some hairy bit of code and needed another pair of eyes and some extra brain power to get to a solution but I've never done it in an ongoing formal context. What I've always wondered is if you get the doubling of productivity required to justify having two resources working on the same bit of code? Certainly in blocking situations you can get a huge multiplier on productivity (I'm including quality and correctness in my definition of productivity) but lots of code is mundane stuff that just needs someone to push through and knock it out. Can a pair get the mundane stuff done in half the time of a solo developer?
- jdlshore 5y ago
  The benefit of a pair in this situation is figuring out the design flaws that make programming repetitive/mundane. If you’re doing a lot of repetitive work, there may be an abstraction you’re missing.
DonHopkins 5y ago
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!
windows2020 5y ago
I'd rather two people independently understand and solve a problem and compare solutions.
- quantumhobbit 5y ago
  I’ve always wanted to try this out in practice. It seems like it would be a great way to find gaps in the specification. There was some research in the early 90’s over multiple implementations as a way to avoid bugs. I still feel like it was dismissed prematurely or could be revisited.
alexashka 5y ago
The greatest anti-pattern is mandating pair programming. The greatest pattern is explaining your goals and seeing if other people's goals align with yours. The chances of that conversation resulting in 'pair programming', is 0%.
ryanmcgarvey 5y ago
> Forgetting it’s a skill > Pair programming is a skill which must be learned. > You will not be good at it at first, but consistent practice will yield improvements. > Don’t give up after a difficult first experience. Don’t assume experienced developers are automatically good pairing partners. Don’t expect to be good without practice. > Consider reflecting with your pair or asking for feedback after each session. What could have been better? In my experience (pairing on and off for about 12 years) - this is the biggest thing people misunderstand about pairing. You're not going to be good at it right away, and the team isn't going to benefit right away. It's an investment that pays off in months not days. That being said - I find that requiring my team to be good at pairing, but not that they pair all day every day, is sufficient. It means that they pair when it's appropriate (onboarding, larger design problems, early stages of a project, etc) and they don't when it's less appropriate (fleshing out an implementation, exploring a new idea, mundane updates). We find that if we pair all the time, especially on things that don't benefit from pairing, it exhausts us. Pairing is a useful tool, but it can be equally dangerous if overused and cause people to resent it.
- Izkata 5y ago
  Also on the "forgetting it's a skill" track: pair programming isn't just one thing. There aren't just two roles, the one at the keyboard and the one not - there's a bunch of different roles you can take on, depending on who you're pairing with and how they (and you) work. For example, with one co-worker at the keyboard, I would fully take on a support role: He was a slow typist, so I'd keep an eye out for typos and quietly nudge him instead of having to wait for a compile/run loop, I'd look up documentation so he wouldn't have to keep context switching, and so on. Before that point though we had roughly equal roles at the design stage (he was a very strong proponent of "keep it simple" and made me realize I was drifting into an "architecture astronaut" mindset, so I think we worked really well together overall). In another, with some co-workers unfamiliar with a codebase but wanting to learn more, I'd take the high-level guidance role where I'd be mentally working a few steps ahead on the overall design/goal while they worked on the nitty-gritty details. They'd be learning how the pieces fit together without having to worry yet about side-effects or other problems because I'd be acting as guardrails, keeping them on the right track and identifying those problems ahead of time so we can deal unavoidable ones right away. Ideally this role doesn't last long with anyone as they'll need to learn those parts on their own, but it works sometimes. As a step up from that second one is on/off pairing, where they'd be testing their knowledge on their own to come up with a solution, then we'd pair for a while to make sure they're on the right path and maybe get past a spot where they were stuck on how to do something.
kaonashi 5y ago
How about just not having a navigator and driver. Having gone through a "wing-it" approach to pairing extensively, it really is an awful experience for those who hate having to fight for control.
seanhunter 5y ago
I'm pretty convinced that pair programming is in and of itself an antipattern.
- Svetlitski 5y ago
  It’s not always the best fit for a particular task, but I’ve personally had some experiences where pair-programming was a huge productivity boon, as it prevented potentially difficult to diagnose bugs from being committed in the first place. I personally feel it shines when you are working on something very complex and particularly detail-sensitive, where a small mistake could cause a devious bug, and so the benefits of having a second set of eyes on everything in real time are large. I’m curious to hear what you dislike about pair-programming.
  - seanhunter 5y ago
    I think it really is complete agony for some people, and when I've seen it in practise, certain people really benefit and others just don't. Speaking for myself, when I'm working on something complex and detail-sensitive, the very last thing I want to do is spend any time at all with anyone else. I want to be able to think properly about the problem without the pressure of having someone else involved.
danielovichdk 5y ago
I don't see pair programming as a disruption to the individual mind of the single programmer. Then I believe something is wrong in culture of the organisation. It should definitely not be enforced but encouraged. The reasons I believe that is because the human psychology is also based around success and praise from our relations. The benefits you get from sharing thoughts and possible options to a challenge can hardly, imo, be bad. Pair programming has taken place in my career, in cultures that encourages a pace to get work done, in a manner where quality is measured by how well a team works together and how well the team is capable of understanding eachother - but as a team. I also believe that if you cannot explain in words, how you would go about solving a challenge, then it's premature to start coding on it. Then you are moving to fast. Pair programming is like any other thing. It should be applied when necessary and not be enforced on 80% of the work because it's perhaps only valid for the hard 20%. I have really thought about making a pair programming service for years, where people can connect and program as a pair, for the hard parts. Good discussion
steelframe 5y ago
I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.
- rajin444 5y ago
  Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".
  - steelframe 5y ago
    > Code reviews prevent this as well, without all the overhead incurred by pair programming. I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.
  - fao_ 5y ago
    Do they? I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
    - yjftsjthsd-h 5y ago
      If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem
      - 5y ago
okareaman 5y ago
Can someone point me to a great work of software that was written by two people simualtaneously collaborating like Lennon and McCarthy writing songs? I never see any evidence given that pair programming is a better way to code.
- compiler-guy 5y ago
  I don't believe pair programming is the only way to develop great code--not by a long shot--but there are certainly examples. Early Google's success came from substantial pair programming by Jeff Dean and Sanjay Ghemawat. Some say Google wouldn't have been successful without this pair working together how they did. https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
  - okareaman 5y ago
    The article paints them like a married couple doing a mind meld. That's impossible to duplicate by making programmers work as a pair. I'd expect the opposite to happen much more often; two programmers forced to share the same monitor and keyboard would start to dislike each other intensely.
- tlyleung 5y ago
  Some projects at Google such as MapReduce, Google File System and TensorFlow were written by Jeff Dean and Sanjay Ghemawat while pair programming. More details, in the form of a long form article, here: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge/ https://www.newyorker.com/magazine/2018/12/10/the-friendship...
salmo 5y ago
I haven't physically paired in years. Even before the pandemic I'd often be screen sharing with someone across the table from me. We'd just be positioned where we could see each others' faces and our own screens. These days it's all fully remote. And that's worked out incredibly well since my team has gotten more and more geographically dispersed. The few that were before are now always in the loop. I haven't done it full time in a while because my responsibilities other than implementation take too much time. I'm old in my team and when I can, it works well for me. I share my experience, keep software focused, etc. The younger, high performers teach me new tools and tech. The fresh folks learn more how to think and do work from us. Stuff like that it's not just about making something work, but making something maintainable. I probably teach as much backspacing through a "clever" idea I had, than by writing anything. That and how to break a problem into chunks. Then reevaluate that and make it clean. Pairing is also great for the more ops side of things. I think in a lot of ways you get even more bang out of it there than programming. Have 1 person do the work and a newer person improve the docs as they go. Then flip for the next iteration, with the new person driving and the experienced one helping and tweaking docs. Call out places where automation could replace procedure and get them in the backlog to be prioritized later. The same pair can pick up those stories when they come back around. I have experienced some of the pains of this list. I worked with a guy who I joked "painted" code. Lines just growing and shrinking like a horizontal EQ. It was dizzying and unpleasant. I often just checked out and pointed out missing braces every once in a while. Same guy brings up an issue not mentioned here for physical pairing: make sure you bathe. Ugh. Also, make sure you're rotating teammates. Sticking in 1 pair can be nice if you like the person... for a while. But it can ruin a friendship if you do that for months. I think the real keys to success there are in luck and management's hands. Make sure you have a mix of maturity and skill sets, and have engaged curious people. Slackers and, uh, "dim" people drag everyone's morale down more in an environment like that. I've lost those teammates and seen team productivity grow. At the same time, it's hard for a team full of people with little to learn from each other to stick with it. It's more engaging when you're teaching or learning or ideally both.
dboreham 5y ago
I'm curious where the pair programming religion came from. There was certainly a time when it didn't exist as a concept. I for sure don't remember anyone suggesting that it would be cool if two folks sat around the ASR-33 and took turns to hunt-n-peck on the keyboard. Perhaps it originated in the brogrammer movement? Anyway, the sibling article says: "A pair of programmers tends to produce better code than someone working alone." Let's assume this is true (I'm reasonably sure it's false). If one programmer can type code that's at quality N, then add a second one to look at what they're typing and perhaps you can say that quality will be >N since the second person might spot errors made by the first. But we just used TWICE as many people to write that "better" code. I expect there are industries where this burning of resources makes sense, but most of the time it won't regardless of the improved code quality achieved. We could write 2x the amount of crappy code and most organizations would opt to do that. If we're pairing up at the terminal to teach/train/transfer knowledge, that makes much sense and has been done since the ASR-33. Also sometimes it helps to have two or more people stare at a debugging session together to crack a gnarly problem. Designing at the whiteboard has been a thing since Von Neumann and Turing (chalk board...) Programming however, isn't a thing you do in pairs, imho. It's creepy and weird.
jnash 5y ago
I would quit if I was forced to pair program. Pair programming is loved by incompetent software developers because they can hide in the shadow of more competent developers. That's my experience anyway. YMMV of course.

247 points by _ttg 5y ago

Forced pair programming is an antipattern. It's a recipe for burning your best workers. You had better hope that the oft-touted knowledge transfer benefits of pairing are real, because you are going to have to deal with the turnover.

ParetoOptimal 5y ago
> Forced pair programming is an antipattern. It's a recipe for burning your best workers. I won't say I totally disagree, but what are your reasons for thinking this?

number6 5y ago

Using two input devices on one PC never occurred to me. Is it just plug and play or does it require some setup ?

Aeolun 5y ago
Based on my connecting multiple boards, I think it’s plug and play. The hard part is if you want to distinguish between what board a keystroke came from.
deleted 5y ago
[deleted]
samatman 5y ago
Users of laptops routinely plug a mouse and keyboard in, while the original trackpad and keyboard continue to work. We don't think anything of it. It's the same thing with two 'exterior' keyboards and mice.
- number6 5y ago
  Mindblown... I do this all the time... wow never thought about sharing a keyboard with somebody else. Blindspot.
namibj 5y ago
Technically it works directly, but with e.g. multi-pointer X you can bind HIDs to a pointer (aka cursor), and control them independently and concurrently as long as you don't confuse the applications you're interacting with. I think Emacs is tolerant in that respect, but beyond that, some trickery is likely required to make this work (i.e., multiple browser instances).

scanr 5y ago

We tried out Live Share (collaborative editing) during pair and mob programming sessions. I enjoyed it a lot - made it feel like a multi-player game. Sometimes it did allow for the equivalent of a pair programmer taking over the keyboard rather than explaining how to solve a problem. I’m curious if anyone has any Live Share patterns / anti-patterns.

jeppester 5y ago
We use live share a lot for pair programming. It works okayish, but the built-in terminal is borderline useless for guests due to its very poor handling of different view port sizes. I recommend to instead let your pair in through SSH (a reverse proxy, like ngrok, is useful), and then sharing a tmux session.
mlloydw 5y ago
I used to do a fair amount over LiveShare and we would adapt depending on the relationship we had. It got more interesting the more level we were. One of the more successful patterns that came out was to: talk about the goal, write out the code that acted as interfaces between the two of us, and then split up and tackle two things at once. That might have been code vs tests, backend vs frontend, migration vs adapting existing code. We would often then swap and discuss what we'd done (and we might be asking little questions as we go to help refine each other's approach), add improvements or plug gaps and then finally give it a good end-to-end run through with some exploration. We were working together on the problem, asynchronously, and you'd be surprised how little there were occasions where a big assumption at the beginning was missed and made us go off in different directions. This was nearly always caught early as we talked whilst we worked on our separate areas and had a quick glance at what the other person was writing. I'm convinced that we caught them faster than if I was alone as we had the opportunity to think about the problem from multiple perspectives at once.

pooya72 5y ago

I've never pair programmed before, so if anyone has any advice like this that they're willing to share it would be helpful.

BoardsOfCanada 5y ago
As someone who has programmed for a very long time but only done pair-programming a lot last few years, the big things in my opinion is: - If you're the driver (handles the typing), don't allow yourself to be stressed and just type things someone else tells you to type. - Language is really bad at comunicating where to make a change on a gigantic screen of text, expect yourself and others to become a bit frustrated at times, but it's at the difficulty of communicating things, not that the other person is dumb. "And change the type to bool. No not that one. Go to the end of the line, then back to the last bracket. No, the line you were at. Yes. Now go to the last bracket. Change to bool." And then take a second to understand why, asking if necessary, becuase it might get more difficult to understand later. - It's extremely difficult not to get lost when someone else is navigating between tabs, especially if you don't know the code well (and sometimes even if you do).
- tialaramex 5y ago
  I would guess that Keep Talking And Nobody Explodes would be a good exercise to learn what the problem is without getting into domain specific skills. https://keeptalkinggame.com/ https://keeptalkinggame.com/ (ideally play this with the defusal in VR) KTANE even has (to a greater extent, and for humour) the ambiguities that can trouble talking to somebody about programming, like offering "YES", "AND", "&" and "NO" as options somebody needs to pick quickly.
- pooya72 5y ago
  That's helpful, thanks!
travisjungroth 5y ago
http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong... Pair programming is terrible by default. You have to work to make it good, but then it can be great.

gregkerzhner 5y ago

Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it. I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work. I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later. Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!

slaymaker1907 5y ago
You missed what I consider to be the greatest strength of pair programming: debugging. If one person gets stuck on something, the other person often still has some ideas on how to proceed. Even if you don't pair program, you absolutely should be debugging with someone else if possible.
jordanbeiber 5y ago
In, for example, an enterprise setting you rarely want individually clever and creative solutions. You generally want domain expertise shared in a team, and continuously molded to perfection over time. Mobs and pairs can really shine here, but it all depends on the individuals. In teams where it works well it’s an enormous value add, in my experience, and the hive mind you reach after a year or two within a team is fantastic. As a dev manager I let the teams decide, but looking at team flow over time, it looks hard to beat a well functioning pair or mob team. IMHO & YMMV, and so on.
epolanski 5y ago
I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons: - knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context - focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck. cons: - you are blocked from working if a coworkers schedule is not aligned Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

skeletal88 5y ago

I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair. Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs. Pairing works for us because it's more efficient than working alone, less bugs and better thought out design, faster spread of knowledge about our tools and the project in general. I joined a year ago and hadn't used Java or IDEA, pairing helped me learn all of it very fast, compared to if I had to work alone and struggle with learning all of the new things.

meken 5y ago
Which company do you work for? I researched pair programming companies a while back and didn’t find any.
- calderwoodra 5y ago
  Large consultancy, pair programs all the time, Java... I would guess Pivotal
  - DLion 5y ago
    Pivotal doesn't exist anymore. It has been acquired by Vmware and now it calls Tanzu Labs: https://tanzu.vmware.com/labs https://tanzu.vmware.com/labs Btw there are many other companies where you can pair: Thoughtworks and Codurance for example
- skeletal88 5y ago
  Not Pivotal or a large consultancy, I'm from Estonia but the company is Codeborne - www.codeborne.com they have been doing it for 12 years soon.
- deleted 5y ago
  [deleted]
- epgui 5y ago
  CircleCI does a lot of pairing.

samuelfekete 5y ago

> Sit so that the monitor is between the two of you. No. Use two monitors that are mirrored or with screen sharing, so that each person can sit comfortably centred on their own screen.

lvspiff 5y ago
Take that one step better and each should have their own resolution. Just cause your 20 yr old eyes looking at a 4k super widescreen monitor can read it doesn't mean my 30 yr old eyes with glasses on a laptop can read it too (I really like code with me on Pycharm)
brrrrrm 5y ago
I've found shared tmux/screen sessions are ideal. + each person can have their own font/resolution + it doesn't dominate the entire screen, allowing each person to keep their own notes/etc on the side + at any point someone can "jump in" and take control of the session + interacting in a confined shared space radically reduces "over communication" issues. i.e. if you want to show something it's got to be demonstrable in a small textual window + you have a shared command-line, which is more useful than it might initially seem + seamlessly scales to in-person and remote pair programming There are some downsides: - it requires both users are familiar with a terminal based editor - it may present security issues for folks operating in locked-down/low-resource environments (e.g. can't spin up a temporary machine with a shared account) - sharing graphical information requires a separate communication layer
- reidrac 5y ago
  Even considering how easy things are using tmate, it is really challenging because there are a lot of Software Engineers that don't really know how to use a terminal to the point that asking to do a SSH is a bit too much. So we end sharing the screen over hang outs, that is basically very inefficient and wastes a lot of CPU. But because it is normalized, it is "the standard". EDIT: my comment was a bit unfair. I guess I could install VS Code, change my daily editor, and use it with the Live Share plugin with those using VS Code. So hang outs it is.

donw 5y ago

The entire guide just worth a read, even if you’re an experienced pair. Lots of great patterns. We do full-time pair programming in my teams, and this guide is part of our “starter pack” for documentation.

reflexco 5y ago
Great resource I agree. The guide is concise and could seem obvious to many peeps, but it made me reflect about my own pair programming sessions and notice I likely failed at a bunch of those points.
- donw 5y ago
  The same. I've been pairing for probably close to a decade now, and this guide helped me to reflect on my own style, and gave me a few points to refine as well. As an aside, one of the things I make sure to do with new hires is to cover "beginner's mind". Just because you've got ten years on the iron doesn't mean you can't learn something new, and that something new might just be from the grass-green new guy that joined last week. Likewise, for the new guys that think they're hot shit because they've got a degree from McSmartypants University doesn't mean you actually know anything. Don't just take things on an "I said so" basis, but also don't discount the value of experience. When you run into a new idea: use active listening to ensure you understand it, and explore its ramifications. Poke and see where it falls down, and where it doesn't. You'll avoid a lot of bullshit this way.

nmisko 5y ago

I'd be interested in such a write up for remote pair programming. Being remote the likelihood is much higher that the navigator loses focus and answers emails or slack instead. Switching roles more quickly might be the solution. We've tried tools like mob.sh, but the most efficient way seems to be using something like VSCodes liveshare. Unfortunately half of my team uses Intellij and the other half VSCode.

deleted 5y ago

[deleted]

codeflo 5y ago

“Allowing unproductive distractions” is one of the major reason why I think home office is fundamentally less productive, no matter how much people have come to like it. Pair programming through screen sharing works fine on a technical level, but you can’t turn off children.

vidarh 5y ago
You can't turn off disruptive co-workers either. When I used to go in to an office of sorts one day a week, I eventually wrote that day off and just accepted that day was for socialising and design meetings. Throughput consistently tanked on those days, so better to accept it and use it for activities that didn't require the same mental focus.
davidmurdoch 5y ago
'“Allowing unproductive distractions” is one of the major reason why I think going in to the office is fundamentally less productive, no matter how much people have come to like it. Pair programming on-site works fine on a technical level, but you can’t turn off co-workers or your managers.' FTFY
Icathian 5y ago
If you don't have someone else watching your children while you work, you're probably not going to have a good time working remote regardless of coding style. Most of us working from home have addressed childcare and aren't just leaving food and water bowls out while they run around doing as they please...

Abroszka 5y ago

I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful. Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.

Icathian 5y ago
Having larger groups collaborate like that is called "mob programming". I'm not sure how popular it actually is but I see it talked about on HN and Reddit all the time.
- MattGaiser 5y ago
  I have a friend currently doing it. It just lets him work on his masters degree all day.

Mountain_Skies 5y ago

I've done plenty of pair programming informally when one of us were stuck on some hairy bit of code and needed another pair of eyes and some extra brain power to get to a solution but I've never done it in an ongoing formal context. What I've always wondered is if you get the doubling of productivity required to justify having two resources working on the same bit of code? Certainly in blocking situations you can get a huge multiplier on productivity (I'm including quality and correctness in my definition of productivity) but lots of code is mundane stuff that just needs someone to push through and knock it out. Can a pair get the mundane stuff done in half the time of a solo developer?

jdlshore 5y ago
The benefit of a pair in this situation is figuring out the design flaws that make programming repetitive/mundane. If you’re doing a lot of repetitive work, there may be an abstraction you’re missing.

DonHopkins 5y ago

When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!

windows2020 5y ago

I'd rather two people independently understand and solve a problem and compare solutions.

quantumhobbit 5y ago
I’ve always wanted to try this out in practice. It seems like it would be a great way to find gaps in the specification. There was some research in the early 90’s over multiple implementations as a way to avoid bugs. I still feel like it was dismissed prematurely or could be revisited.

alexashka 5y ago

The greatest anti-pattern is mandating pair programming. The greatest pattern is explaining your goals and seeing if other people's goals align with yours. The chances of that conversation resulting in 'pair programming', is 0%.

ryanmcgarvey 5y ago

> Forgetting it’s a skill > Pair programming is a skill which must be learned. > You will not be good at it at first, but consistent practice will yield improvements. > Don’t give up after a difficult first experience. Don’t assume experienced developers are automatically good pairing partners. Don’t expect to be good without practice. > Consider reflecting with your pair or asking for feedback after each session. What could have been better? In my experience (pairing on and off for about 12 years) - this is the biggest thing people misunderstand about pairing. You're not going to be good at it right away, and the team isn't going to benefit right away. It's an investment that pays off in months not days. That being said - I find that requiring my team to be good at pairing, but not that they pair all day every day, is sufficient. It means that they pair when it's appropriate (onboarding, larger design problems, early stages of a project, etc) and they don't when it's less appropriate (fleshing out an implementation, exploring a new idea, mundane updates). We find that if we pair all the time, especially on things that don't benefit from pairing, it exhausts us. Pairing is a useful tool, but it can be equally dangerous if overused and cause people to resent it.

Izkata 5y ago
Also on the "forgetting it's a skill" track: pair programming isn't just one thing. There aren't just two roles, the one at the keyboard and the one not - there's a bunch of different roles you can take on, depending on who you're pairing with and how they (and you) work. For example, with one co-worker at the keyboard, I would fully take on a support role: He was a slow typist, so I'd keep an eye out for typos and quietly nudge him instead of having to wait for a compile/run loop, I'd look up documentation so he wouldn't have to keep context switching, and so on. Before that point though we had roughly equal roles at the design stage (he was a very strong proponent of "keep it simple" and made me realize I was drifting into an "architecture astronaut" mindset, so I think we worked really well together overall). In another, with some co-workers unfamiliar with a codebase but wanting to learn more, I'd take the high-level guidance role where I'd be mentally working a few steps ahead on the overall design/goal while they worked on the nitty-gritty details. They'd be learning how the pieces fit together without having to worry yet about side-effects or other problems because I'd be acting as guardrails, keeping them on the right track and identifying those problems ahead of time so we can deal unavoidable ones right away. Ideally this role doesn't last long with anyone as they'll need to learn those parts on their own, but it works sometimes. As a step up from that second one is on/off pairing, where they'd be testing their knowledge on their own to come up with a solution, then we'd pair for a while to make sure they're on the right path and maybe get past a spot where they were stuck on how to do something.

kaonashi 5y ago

How about just not having a navigator and driver. Having gone through a "wing-it" approach to pairing extensively, it really is an awful experience for those who hate having to fight for control.

seanhunter 5y ago

I'm pretty convinced that pair programming is in and of itself an antipattern.

Svetlitski 5y ago
It’s not always the best fit for a particular task, but I’ve personally had some experiences where pair-programming was a huge productivity boon, as it prevented potentially difficult to diagnose bugs from being committed in the first place. I personally feel it shines when you are working on something very complex and particularly detail-sensitive, where a small mistake could cause a devious bug, and so the benefits of having a second set of eyes on everything in real time are large. I’m curious to hear what you dislike about pair-programming.
- seanhunter 5y ago
  I think it really is complete agony for some people, and when I've seen it in practise, certain people really benefit and others just don't. Speaking for myself, when I'm working on something complex and detail-sensitive, the very last thing I want to do is spend any time at all with anyone else. I want to be able to think properly about the problem without the pressure of having someone else involved.

danielovichdk 5y ago

I don't see pair programming as a disruption to the individual mind of the single programmer. Then I believe something is wrong in culture of the organisation. It should definitely not be enforced but encouraged. The reasons I believe that is because the human psychology is also based around success and praise from our relations. The benefits you get from sharing thoughts and possible options to a challenge can hardly, imo, be bad. Pair programming has taken place in my career, in cultures that encourages a pace to get work done, in a manner where quality is measured by how well a team works together and how well the team is capable of understanding eachother - but as a team. I also believe that if you cannot explain in words, how you would go about solving a challenge, then it's premature to start coding on it. Then you are moving to fast. Pair programming is like any other thing. It should be applied when necessary and not be enforced on 80% of the work because it's perhaps only valid for the hard 20%. I have really thought about making a pair programming service for years, where people can connect and program as a pair, for the hard parts. Good discussion

steelframe 5y ago

I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.

rajin444 5y ago
Code reviews prevent this as well, without all the overhead incurred by pair programming. I think pair programming has its uses, but unless the 2 working together are on the same level it's really hard to get into "flow".
- steelframe 5y ago
  > Code reviews prevent this as well, without all the overhead incurred by pair programming. I'm a big believer in correcting errant behavior in the moment. Simply the presence of an overseer can coerce a developer to avoid taking shortcuts with the hope that it might go overlooked in an asynchronous code review.
- fao_ 5y ago
  Do they? I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
  - yjftsjthsd-h 5y ago
    If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem
    - 5y ago

okareaman 5y ago

Can someone point me to a great work of software that was written by two people simualtaneously collaborating like Lennon and McCarthy writing songs? I never see any evidence given that pair programming is a better way to code.

compiler-guy 5y ago
I don't believe pair programming is the only way to develop great code--not by a long shot--but there are certainly examples. Early Google's success came from substantial pair programming by Jeff Dean and Sanjay Ghemawat. Some say Google wouldn't have been successful without this pair working together how they did. https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
- okareaman 5y ago
  The article paints them like a married couple doing a mind meld. That's impossible to duplicate by making programmers work as a pair. I'd expect the opposite to happen much more often; two programmers forced to share the same monitor and keyboard would start to dislike each other intensely.
tlyleung 5y ago
Some projects at Google such as MapReduce, Google File System and TensorFlow were written by Jeff Dean and Sanjay Ghemawat while pair programming. More details, in the form of a long form article, here: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge/ https://www.newyorker.com/magazine/2018/12/10/the-friendship...

salmo 5y ago

I haven't physically paired in years. Even before the pandemic I'd often be screen sharing with someone across the table from me. We'd just be positioned where we could see each others' faces and our own screens. These days it's all fully remote. And that's worked out incredibly well since my team has gotten more and more geographically dispersed. The few that were before are now always in the loop. I haven't done it full time in a while because my responsibilities other than implementation take too much time. I'm old in my team and when I can, it works well for me. I share my experience, keep software focused, etc. The younger, high performers teach me new tools and tech. The fresh folks learn more how to think and do work from us. Stuff like that it's not just about making something work, but making something maintainable. I probably teach as much backspacing through a "clever" idea I had, than by writing anything. That and how to break a problem into chunks. Then reevaluate that and make it clean. Pairing is also great for the more ops side of things. I think in a lot of ways you get even more bang out of it there than programming. Have 1 person do the work and a newer person improve the docs as they go. Then flip for the next iteration, with the new person driving and the experienced one helping and tweaking docs. Call out places where automation could replace procedure and get them in the backlog to be prioritized later. The same pair can pick up those stories when they come back around. I have experienced some of the pains of this list. I worked with a guy who I joked "painted" code. Lines just growing and shrinking like a horizontal EQ. It was dizzying and unpleasant. I often just checked out and pointed out missing braces every once in a while. Same guy brings up an issue not mentioned here for physical pairing: make sure you bathe. Ugh. Also, make sure you're rotating teammates. Sticking in 1 pair can be nice if you like the person... for a while. But it can ruin a friendship if you do that for months. I think the real keys to success there are in luck and management's hands. Make sure you have a mix of maturity and skill sets, and have engaged curious people. Slackers and, uh, "dim" people drag everyone's morale down more in an environment like that. I've lost those teammates and seen team productivity grow. At the same time, it's hard for a team full of people with little to learn from each other to stick with it. It's more engaging when you're teaching or learning or ideally both.

dboreham 5y ago

I'm curious where the pair programming religion came from. There was certainly a time when it didn't exist as a concept. I for sure don't remember anyone suggesting that it would be cool if two folks sat around the ASR-33 and took turns to hunt-n-peck on the keyboard. Perhaps it originated in the brogrammer movement? Anyway, the sibling article says: "A pair of programmers tends to produce better code than someone working alone." Let's assume this is true (I'm reasonably sure it's false). If one programmer can type code that's at quality N, then add a second one to look at what they're typing and perhaps you can say that quality will be >N since the second person might spot errors made by the first. But we just used TWICE as many people to write that "better" code. I expect there are industries where this burning of resources makes sense, but most of the time it won't regardless of the improved code quality achieved. We could write 2x the amount of crappy code and most organizations would opt to do that. If we're pairing up at the terminal to teach/train/transfer knowledge, that makes much sense and has been done since the ASR-33. Also sometimes it helps to have two or more people stare at a debugging session together to crack a gnarly problem. Designing at the whiteboard has been a thing since Von Neumann and Turing (chalk board...) Programming however, isn't a thing you do in pairs, imho. It's creepy and weird.

jnash 5y ago

I would quit if I was forced to pair program. Pair programming is loved by incompetent software developers because they can hide in the shadow of more competent developers. That's my experience anyway. YMMV of course.