[HN Gopher] Pair Programming Antipatterns
___________________________________________________________________
Pair Programming Antipatterns
Author : _ttg
Score : 202 points
Date : 2022-03-06 08:55 UTC (14 hours ago)
(HTM) web link (tuple.app)
(TXT) w3m dump (tuple.app)
| nmisko wrote:
| 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.
| scanr wrote:
| 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 wrote:
| 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.
| pooya72 wrote:
| I've never pair programmed before, so if anyone has any advice
| like this that they're willing to share it would be helpful.
| spaetzleesser wrote:
| Only pair with people who are genuinely interested in learning
| new stuff, want to do better and who are able to listen to
| other viewpoints and exchange ideas. Pairing with people who
| don't care to learn or are super opinionated is a nightmare.
| Ideally you would have hired only people of the former kind but
| in the real world that is often not the case.
| travisjungroth wrote:
| 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.
| BoardsOfCanada wrote:
| 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 wrote:
| 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/ (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 wrote:
| That's helpful, thanks!
| DonHopkins wrote:
| 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 wrote:
| I'd rather two people independently understand and solve a
| problem and compare solutions.
| quantumhobbit wrote:
| 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.
| Abroszka wrote:
| 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 wrote:
| 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 wrote:
| I have a friend currently doing it. It just lets him work on
| his masters degree all day.
| ryanmcgarvey wrote:
| > 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 wrote:
| 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.
| [deleted]
| gregkerzhner wrote:
| 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!
| epolanski wrote:
| 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.
| eikenberry wrote:
| > Overall I think pair programming makes in my, and most
| organizations produce more work than if the contributors
| where solo programming.
|
| I think this is the key takeaway with one missed point. IMO
| it definitely does produce more work vs. solo programming but
| that work is sub-par. The necessary time isn't spent thinking
| on the tasks but instead the pairing rushing things through
| with very little thought to design and long term
| maintainability.
| gregkerzhner wrote:
| The part of my brain which thinks deeply and produces
| elegant solutions simply shuts down when I constantly have
| to explain my thought process to someone else. I actually
| have the same problem in pair programming interviews - my
| brain tends to freeze up and comes up with strange, hacky
| workarounds at best.
|
| Later, when I'm alone and can focus the proper answer
| usually comes to me. I know there are others like me who
| produce their best work when they can focus, alone.
|
| If pairing works for you, then that's great, but it needs
| to be consensual and optional.
|
| The problem with pairing is that it tends to be championed
| and enforced by more social workers (especially managers),
| and forced on the less social ones, who are often not in a
| position to refuse.
| RHSeeger wrote:
| > If pairing works for you, then that's great, but it
| needs to be consensual and optional.
|
| This is the key in my mind. Pair programming doesn't work
| for me, based on past experience. Pair design works
| great, and rubber ducking into a slack channel (that
| people expect that kind of thing to be in); those are
| things I find highly useful. But when it comes time to
| actually write code, I tend to work best alone.
|
| I think part of the reason for this is that I tend to
| work through designs and possible implementations in my
| head, but by writing code. Then I'll discuss those
| designs to come up with some possible issues
| (pros/cons/etc). Then I'll work on implementing what
| seems likely to be the best choice (which is may not be
| once coding starts). By the time I get to coding, most of
| the impact of someone else being involved is just going
| to be catching typos. Or possibly code written in a hard
| to maintain way... but code reviews will catch that just
| as well (probably more so, because the person reviewing
| it _wasn't_ there when it was written).
| ParetoOptimal wrote:
| > Later, when I'm alone and can focus the proper answer
| usually comes to me. I know there are others like me who
| produce their best work when they can focus, alone.
|
| Yeah, I've taken "thinking breaks" during pair sessions
| for this reason.
| ParetoOptimal wrote:
| > The necessary time isn't spent thinking on the tasks but
| instead the pairing rushing things through with very little
| thought to design and long term maintainability.
|
| I feel like pairing pushes people towards this because both
| parties feel the need to show they aren't "wasting time" by
| engines reasonable definition of it.
|
| If you swim upstream and try to work against this, it can
| cause some friction.
| Chris_Newton wrote:
| _The necessary time isn 't spent thinking on the tasks but
| instead the pairing rushing things through with very little
| thought to design and long term maintainability._
|
| Indeed, and this is a problem that can affect other "Agile"
| practices too. Mandatory/permanent pairing is one example.
| TDD is another. Both can reflect a more general trend to
| try to break development down into tiny steps.
|
| It's not that there is no value in developers working
| together in real time, or in unit tests, or in incremental
| development and short feedback loops. All of these can be
| very useful. In my experience, they are often adopted
| spontaneously by developers even if there is no formal
| process in place that requires them.
|
| But it's also important to look at the big picture. You
| need a coherent vision for the product. You need a
| consistent domain model that is well understood and shared
| by both developers and non-developers. You need a
| reasonable software architecture that provides useful
| patterns and abstractions but also isn't afraid to change
| them as requirements evolve.
|
| Without these things, it's easy to take a lot of small
| steps and create an illusion of progress, yet not move
| efficiently towards your true goal. Increasingly serious
| problems tend to get shoved under the carpet (sorry, "added
| to the backlog" or "labelled as tech debt") until
| inevitably quality and productivity start to suffer.
|
| You can't fix those kinds of problems working in the small
| with only one or two participants.
| jatins wrote:
| Google's Jeff and Sanjay are famous for pairing together, and
| most would think they are fairly competent people.
|
| Pairing brings a new perspective to the problem and, for me,
| the social element is also valuable in that you also build
| relationships by pairing.
|
| Though it's completely possible what you and I think when we
| say "pairing" might be different. For example, the ability to
| not check Twitter feed would only be an issue if you are
| pairing for hours at stretch. While my pairing sessions are
| rarely longer than an hour.
| soneca wrote:
| If they are pairing to do high level design, then you are not
| disagreeing with GP
| coryrc wrote:
| I was just looking at their changes recently, plenty of
| regular improvements to code.
| brandall10 wrote:
| Some companies do a strict all-day XP style pairing session,
| where a paired team works on a synced schedule (clock-
| in/clock-out/meetings/lunch). Pivotal Labs in particular
| follows this model.
| jenscow wrote:
| That's your problem with pairing - you're able to think deeply,
| so pairing is a hindrance to you.
|
| The majority of developers, in enterprise at least, tend to
| write the first piece of code that enters their head, and they
| only consider the immediate problem. The code Just Works, so
| pairing is sufficient for them.
|
| Whenever I've driven a pair session, I tend to go back and
| finish it - fill in the blanks: handle edge cases, tests,
| security, a11y, etc.
|
| Pairing is a good tool for creating prototypes or combining
| ideas, and in imbalanced situations like you say. But for long-
| term stable production, code reviews are generally more
| suitable.
| vidarh wrote:
| I hate it enough for day to day use that I'd leave a job over
| it if I was forced to.
|
| It's fine occasionally for training, as you suggest, or for
| explaining a design to people, but like you I feel it's an
| encroachment.
|
| Thankfully I'm experienced enough that I can afford to refuse
| to take jobs that impose it.
| beebmam wrote:
| It's funny, I have the opposite perspective. For me, I think
| design, or brainstorming, is best done independently after long
| periods of time of thinking unconsciously about the problem.
| lenkite wrote:
| Pair Programming always has some ramp-up "friction" time with a
| new partner where you get over the awkwardness and embarrassing
| phases (ashamed to make mistakes in front on each other).
|
| And there are some partners you will simply be unable to pair
| with unless both of you take the time to give each other
| significant space/time. (ugghh..that sounds like some corny
| relationship therapy).
|
| But when it's going smoothly, wow, you can code large blocks of
| code in a few sessions and the structure/design of code comes
| out looking really good. You can refine each others ideas as
| you code or even arrive at something better when the flaws are
| pointed out in the individual approaches.
|
| I have also tried tri-programming also where a third guy joins
| in for miscellaneous stuff like quick exploration, how-to-do-
| that's or research activity while the primary pair focuses on
| the main backlog. This is helpful because when you are in the
| groove, you really don't want to get side-tracked.
|
| I am a social, introverted recluse and even I found pair-
| programming objectively useful.
|
| It all sucks doing it remotely though and frankly not worth it.
| koide wrote:
| I've paired remotely and haven't found it particularly
| problematic. Even without plugins, which tend to suck. Driver
| shares the screen with the ide, zooms it up, and it's good
| enough to be useful in my experience.
| XorNot wrote:
| > It all sucks doing it remotely though and frankly not worth
| it.
|
| I find this perspective wild. I cannot possibly imagine pair
| programming as productive, or tolerable if it was being done
| in person.
|
| Whereas doing it using screen sharing tools from the comfort
| of my home (or private office but who's had one of those
| recently?) - well I've actually done this, and it worked
| great. No body hygiene or smell issues to get with, no one
| snacking or drinking near you, no crowding or extra CO2 and
| sweat - just a nice tight feedback loop which people can dip
| in and out of without disruption, join and stop easily etc.
|
| The idea of pair programming with other people physically in
| the room with you...I can't think of anything more
| unpleasant.
| slaymaker1907 wrote:
| 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.
| dimmke wrote:
| I have to pair program all the time at my job. It's just the
| nature of a lot of the work I do. However, all the pair
| programming I do is over screensharing where we aren't
| physically next to each other. The tips in this article are
| _excellent_.
|
| The two big ones that will make me hate pair programming with
| you: Leaping on errors too quickly and giving low-level
| instructions.
|
| The big sin I commit: Driving too fast
|
| When pair programming is going well, it really does speed up
| development time and increases the amount of people who know
| about a section of a codebase which is always good. But when
| it's bad, it's really really bad.
| wowokay wrote:
| I am of the same mind, I found value in pairing on small tasks,
| or maybe a code review/training, but generally I find it
| promotes 2 negative concepts.
|
| 1. That all developers can do/produce the same results.
|
| 2. That some people become dependent on others to write code.
|
| #1 fuels the management misconception that hiring or moving
| devs will result in more work getting done.
|
| #2 makes some individuals short change the PR review process.
| (I.E I was there when it was written, or I trust that pair
| thought through all the steps.
|
| I think it's great in a lot of situations, where something new
| is being started or for KTing, but as a daily practice it
| reminds me of those old school group projects where 1 person
| does all the work and the other gets the credit.
| nkingsy wrote:
| I'll agree that two senior engineers pairing can feel painful
| and slow compared to each working solo.
|
| I'm currently doing pairing sessions with two junior engineers
| and it's been great for everyone.
|
| I'm also pairing for 2 hrs/wk with the other senior engineer on
| the team to explore an ambitious new project, and it feels like
| we just constantly grate on each other with slightly different
| designs in our heads.
|
| I will say, though, that the conflict our pairing generates is
| valuable as it often illuminates decision points that would be
| good to escalate to the larger working group.
| Mezzie wrote:
| It's SO task dependent.
|
| I'm happy to work this way when I'm doing UI/UX or end-user
| touching work; so much of that boils down to 'predicting the
| ways in which the chaos apes will behave' that having another
| perspective is useful.
|
| When I'm doing database design, don't talk to me unless I ask
| you to: All it does is make me want to choke you and take me
| out of the flow.
| jordanbeiber wrote:
| 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.
| ryanbrunner wrote:
| > 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.
|
| IMO this is a very wrong way to look at pairing. It's not about
| one person being incapable of delivering a solution on their
| own, it's that having multiple perspectives on the code will
| lead to a higher quality and more well designed product.
|
| You could use the same argument you're using to say we
| shouldn't do code reviews, because we should trust that every
| developer is competent.
|
| Also, at least in my experience, design isn't primarily or even
| mostly confined to an initial design phase. Most of the
| 'design' of a problem occurs when you're actually coding.
| sidlls wrote:
| "IMO this is a very wrong way to look at pairing. It's not
| about one person being incapable of delivering a solution on
| their own, it's that having multiple perspectives on the code
| will lead to a higher quality and more well designed
| product."
|
| That's what PRs are for. One can't use the same argument to
| oppose PRs, as you suggest, because of this key difference:
| in a PR, the person doing the review has (or ought to have)
| context on the broader picture (e.g. overall architecture,
| structure of the code in which the change is being made,
| etc.), but not the specific changes. It's analogous to having
| a proof reader: one doesn't invite a peer author to review
| his writings, because the peer has an implicit bias and can
| easily miss defects.
|
| "Also, at least in my experience, design isn't primarily or
| even mostly confined to an initial design phase. Most of the
| 'design' of a problem occurs when you're actually coding."
|
| This is common, unfortunately, and one of the primary reasons
| software is so buggy and overly complex. The code isn't the
| design, or shouldn't be. To draw an analogy to
| physical/industrial processes, the code is the machinery on
| the factory floor doing the work--the design is what was used
| as a blueprint to construct that machinery.
| slaymaker1907 wrote:
| As the design evolves, this stuff should really be
| communicated to the rest of the team before the PR. The
| purpose of PRs should be almost entirely about finding bugs
| and typos.
| ParetoOptimal wrote:
| What are "draft PRs" for then?
| moron4hire wrote:
| Nah, it's about management weaponizing coworkers against each
| other to make sure nobody is "goofing off".
| bartread wrote:
| > it's that having multiple perspectives on the code will
| lead to a higher quality and more well designed product.
|
| Will it though, when those multiple perspectives are enforced
| through pair programming?
|
| Like a lot of agile cargo-culting, pair programming often
| seems like software development for extroverts. Those of us
| who are introverts, and got into software development because
| it's interesting work which suits our temperaments, don't
| necessarily appreciate this... at all. I'm not saying I'm
| unwilling to work with others, or figure out problems
| together - I have to do this all the time, we all do - but I
| prefer to program alone.
| steelframe wrote:
| > I prefer to program alone.
|
| I think a developer has to earn that privilege. Often times
| developers use the "just let me do my own thing by myself"
| line to push code they know is crap, just because they
| don't get the same level of scrutiny and accountability
| through an asynchronous code review. Asynchronously, the
| code reviewer isn't easily able to see the author's thought
| processes as they constructed their code, so they don't
| really know whether the author's way of solving the problem
| is reasonable given the context without putting in
| significantly more effort into reading the entire context
| in which the change was written.
|
| After having dealt with mountains and mountains of
| technical debt in my career, I'm firmly of the opinion that
| every developer should go through a period of pair
| programming with a more senior developer. Maybe they can do
| it for their first quarter with the company. At that point,
| if the senior developer signs off, they can acquire the
| right to code independently if they so desire.
| vidarh wrote:
| My experience is that pairing is deeply disruptive to my
| exploration of a design. It forces me to slow down and
| verbalise something that I can clearly visualise in my mind,
| when the fastest way to externalise it for me is often to
| write the code and show it. I'm happy to walk people through
| a prototype afterwards and discuss it and if necessary throw
| the thing away and start over or significant revise it. I'm
| not happy to have someone disrupt my thinking about a problem
| while I'm trying to focus.
|
| Fundamentally I tend to think that people who insist pairing
| is ok to impose on people think everyone is like them, and
| don't see that it's forcing out people with different ways of
| thinking and processing problems. Ultimately I think it's
| bordering on discriminatory in that it's selecting for
| extroverts who don't burn out by the extensive amount of
| interpersonal contact pairing forces rather than selecting
| for results.
|
| For my part I will _never_ work somewhere that imposes
| pairing. I 'd rather leave software development altogether
| than suffer through that, because it's not worth the
| exhaustion and the reduction in throughput other than
| occasionally (e.g. while training someone or walking people
| through a prototype). Thankfully I have the luxury of not
| having to take that shit.
| whynotminot wrote:
| > My experience is that pairing is deeply disruptive to my
| exploration of a design.
|
| I think it's one of those things where some people are good
| at it / enjoy it. Some people don't.
|
| As a paradigm, I think pairing is better. Two talented,
| smart people who are able to work together will produce a
| better solution than one person alone. As you rotate pairs,
| context on the code base is shared and permeates the team
| faster. New onboards get up to speed at a remarkable pace--
| far better than the "uhhh so checkout the code. Mess
| around, see if you can get things running. Idk good luck"
| process I usually see on non-pairing teams.
|
| I've seen a lot of code over the years developed in silos
| by talented people. The work gets done. But the teams I've
| been on that embrace pairing produce better code, the team
| has better shared context, and there's a real joy to the
| work. This becomes disrupted when someone who does not like
| pairing joins the team, and actively resists the process,
| hoarding context and cowboy-ing solutions off on their own.
|
| If I ever run a company, I will select for engineers who
| aren't just comfortable with pairing, but actively enjoy
| it.
|
| I think companies can perfectly well operate with lone wolf
| engineers. But you have to add a lot of process to wrap
| that mentality--code reviews, design sessions, context
| share-outs, multiple people singing off on PRs. These are
| things you can largely do away with if you're doing pairing
| correctly.
|
| From my experience, it's just better. But hey, I'm biased.
| I'm one of those people that enjoy it.
| vidarh wrote:
| > Two talented, smart people who are able to work
| together will produce a better solution than one person
| alone.
|
| The issue I have with this statement is that working
| together does not require pairing. I _agree_ with your
| statement, but not as support for pair programming.
|
| > As you rotate pairs, context on the code base is shared
| and permeates the team faster. New onboards get up to
| speed at a remarkable pace--far better than the "uhhh so
| checkout the code. Mess around, see if you can get things
| running. Idk good luck" process I usually see on non-
| pairing teams.
|
| None of this requires pairing to address. I _do_ address
| this by sitting down with people and walking through
| code, to give an overview or when people have a concrete
| problem. A big problem I see with pairing in this context
| is that it promotes _not learning how to learn from
| code_. I see this often when I 'm brought in to
| troubleshoot code with developers who look like deer in
| headlights when they are dealing with something out of
| the ordinary, because they've learned the hot spots of
| the code rather than actually reading through and
| understanding the conceptual basis of the system and the
| design behind it.
|
| > If I ever run a company, I will select for engineers
| who aren't just comfortable with pairing, but actively
| enjoy it.
|
| Having run companies, and hired many dozens of engineers,
| if you do so you'll end actively discriminating against
| many types of neuro-divergent people. Apart from the
| issue of whether or not you can actually show any
| benefits, you'll be one little conflict away from a
| lawsuit.
|
| > I think companies can perfectly well operate with lone
| wolf engineers.
|
| This is a false dichotomy. Nobody here has argued for
| "lone wolf engineers" as far as I can see.
|
| > But you have to add a lot of process to wrap that
| mentality--code reviews, design sessions, context share-
| outs, multiple people singing off on PRs. These are
| things you can largely do away with if you're doing
| pairing correctly.
|
| If you do away with those things just because you're
| pairing, you're setting yourself up for massive risks and
| failures.
| whynotminot wrote:
| > Having run companies, and hired many dozens of
| engineers, if you do so you'll end actively
| discriminating against many types of neuro-divergent
| people. Apart from the issue of whether or not you can
| actually show any benefits, you'll be one little conflict
| away from a lawsuit.
|
| "We pair program here--that means actively working with
| another engineer for 8 hours a day. Is this something
| you're comfortable with?"
|
| "No. But knowing this, I am going to still pursue this
| job. I will then sue you when I'm unhappy with the
| requirements you've clearly outlined to me."
|
| What a world.
| jdlshore wrote:
| It's not the world, it's GPs fantasy.
| vidarh wrote:
| > What a world.
|
| A whole lot of unwillingness to make reasonable
| accommodations for people based on disabilities will open
| you up to lawsuits.
|
| To imply reasonable accommodations for neuro-divergent
| people is simply a matter of "comfort" is indeed worth a
| "what a world" on the same level as refusing to make
| reasonable accommodations for those who are blind or hard
| of hearing or in a wheelchair.
| whynotminot wrote:
| > A whole lot of unwillingness to make reasonable
| accommodations for people based on disabilities will open
| you up to lawsuits.
|
| I kind of take issue with your assumption that someone
| with (edit: meant Neurodivergent... NPD is something
| else) can't pair program.
|
| If your assumption of an effective pair programmer is
| that they're always bubbly extroverts with politician-
| level shmoozing capability, I kind of doubt you've spent
| any length of time doing it.
|
| There's a lot of people who struggle with more "normal"
| communication that are incredible pair programmers. I've
| worked with many of them. In many cases, the code and the
| keyboard becomes a communication medium they're effective
| at leveraging--more than other means. Actually doing pair
| programming challenged a lot of my misconceptions about
| what it takes to be good at it.
|
| It's skill and like any other should be disconnected from
| stereotypes. I don't see why you can't hire for it like
| any other. Hopefully I don't run into you in the court
| room. ;-)
| vidarh wrote:
| > I kind of take issue with your assumption that someone
| with NPD can't pair program.
|
| Many can. Many can't. I did not make the assumption
| you're arguing against here.
|
| > If your assumption of an effective pair programmer is
| that they're always bubbly extroverts with politician-
| level shmoozing capability, I kind of doubt you've spent
| any length of time doing it.
|
| That was not my assumption at all. You're jumping to
| unwarranted conclusions not at all supported by what I
| wrote.
|
| > There's a lot of people who struggle with more "normal"
| communication that are incredible pair programmers.
|
| That's fine, but it does not change the fact that many
| people struggle with it. Including people who manage to
| deal with "normal" communication just fine, but who find
| the intensity of a pairing unbearable. I _can_ do it, but
| to me it is intensely uncomfortable to the point that as
| I 've pointed out elsewhere I refuse to be pushed into it
| - for me it's not a problem, as my career has afforded me
| the luxury of picking and choosing positions where I get
| to decide what goes -, but I've met many brilliant
| developers over the years who just could not deal with
| situations like that at all.
|
| > It's skill and like any other should be disconnected
| from stereotypes.
|
| This dismissal of what to quite a few people is an
| inherent part of their neurological makeup as a "skill"
| comes across to me as incredibly offensive.
| whynotminot wrote:
| > That's fine, but it does not change the fact that many
| people struggle with it. Including people who manage to
| deal with "normal" communication just fine, but who find
| the intensity of a pairing unbearable. I can do it, but
| to me it is intensely uncomfortable to the point that as
| I've pointed out elsewhere I refuse to be pushed into it
| - for me it's not a problem, as my career has afforded me
| the luxury of picking and choosing positions where I get
| to decide what goes -, but I've met many brilliant
| developers over the years who just could not deal with
| situations like that at all.
|
| I'm not disagreeing that some people don't find it
| enjoyable, and some people aren't good at it. Like
| anything else.
|
| I don't see why you just wouldn't work at another company
| instead of demanding the company change its methodologies
| for you. I'd say the _average dev shop_ leans more "lone
| wolf" anyway. Teams and especially companies that pair
| are the exception, not the norm. You're an experienced
| guy it seems like--I'm sure you've changed jobs many
| times in the past to find a culture and working
| conditions that suited you better.
|
| > This dismissal of what to quite a few people is an
| inherent part of their neurological makeup as a "skill"
| comes across to me as incredibly offensive.
|
| I'm sorry my view on this offensive to you. I don't mean
| to offend you, but simply stating you're offended doesn't
| change my perspective--I still view pair programming as a
| skill, and I don't think it's wrong to hire for skills.
| vidarh wrote:
| > I'm not disagreeing that some people don't find it
| enjoyable, and some people aren't good at it. Like
| anything else.
|
| I'm not saying that some people don't find it enjoyable.
| I'm saying that some people _can 't do it_ without
| risking their health.
|
| > I don't see why you just wouldn't work at another
| company instead of demanding the company change its
| methodologies for you.
|
| Most people do, or end up unemployed. This is a
| widespread problem with the lack of protection of
| employment opportunities for differently abled, and a
| reason why I find it immoral to refuse to make reasonable
| accommodations based on it, the same way I'd rather walk
| from a job than e.g. refuse to hire someone just because
| they're blind or deaf. That a whole lot of companies do
| just fine without pair programming, to me is clear
| evidence that it's a reasonable accommodation.
|
| > I'd say the average dev shop leans more "lone wolf"
| anyway.
|
| Either we have very different ideas about what "lone
| wolf" implies, or I deeply disagree with this. But in
| terms of not mandating pair programming, sure. I don't
| see that as an indicator of people being "lone wolf" type
| programmers, however.
|
| But the existence of less discriminatory environments is
| not a justification for accepting discrimination.
|
| Note that I have _no_ issue with companies choosing to
| prefer pair programming. It 's their business, though I'd
| probably still not want to work there (and that's my
| business). What I do have an issue with are those who
| outright demand it of everyone and are unwilling to make
| adjustments.
| gregkerzhner wrote:
| Ultimately, I file (mandatory, full time) pairing in the
| same category as mandatory in-office work, meant to
| encourage brilliance from random water cooler
| interactions.
|
| In a perfect world, is a fully engaged in-office employee
| better than a remote one? I'd say probably yes. In the
| real world, is a disgruntled, commute tired employee
| better than a happy remote one? Unknown.
|
| Same with paring. If your team is full of perfectly
| interchangeable humans drinking the same cool aid, then
| pairing sounds great. But real humans don't work like
| that, and for every person who is boosted by pairing
| there may be another who is held back by it.
|
| In the end, it's likely best to allow employees to self
| select the mode of work which works best for them
| (location, pairing amount, computer choice) so that they
| are happy and productive. Any kind of top down mandatory
| policy on those choices will inevitably be worse than
| each person's preferred choice.
| whynotminot wrote:
| > Ultimately, I file (mandatory, full time) pairing in
| the same category as mandatory in-office work
|
| I don't really disagree with this categorization. And
| there's a lot of companies that view it as core to their
| success and culture to have an in person work force.
|
| I may disagree, and I may work elsewhere that suits me
| better!
|
| That's sort of why this digression on denying a company
| the ability to set their own development practices is
| strange to me. There's a plethora of options for the work
| force. Go where you're in alignment, don't force bad
| alignment on the company!
| [deleted]
| jdlshore wrote:
| > one little conflict away from a lawsuit
|
| I find this hard to believe. Which country's laws are you
| thinking of? In the US, at least, companies such as
| Pivotal and Menlo Innovations, as well as others I'm not
| at liberty to name, require full-time pairing. They've
| never had an issue. Your statement is also at odds with
| my understanding of employment law, which is admittedly
| at a layman's level, but I have studied it for the
| purpose of hiring in Oregon.
|
| > setting yourself up for massive risks and failures
|
| You're losing credibility with me. I've done exactly what
| GP is talking about and it was _better_ than code reviews
| (etc), not worse. Are you talking from experience, or
| from personal preference?
| vidarh wrote:
| > I find this hard to believe. Which country's laws are
| you thinking of? In the US, at least, companies such as
| Pivotal and Menlo Innovations, as well as others I'm not
| at liberty to name, require full-time pairing. They've
| never had an issue. Your statement is also at odds with
| my understanding of employment law, which is admittedly
| at a layman's level, but I have studied it for the
| purpose of hiring in Oregon.
|
| I'm in Europe, but I've seen such law suits and threats
| of lawsuits over issues like this affect companies I've
| done projects for first hand, including at least one US
| company. They are very hard to make stick, because most
| people are not dumb enough to make statements that are
| clear cut enough to provide proof that the employees
| failure to get hired is discrimination. But that does not
| stop people from suing (or threatening to sue). I've seen
| team paralysed for months [dealing with legal issues
| surrounding conflicts over discriminatory hiring
| practices] instead of doing their jobs. I've also
| personally seen people walk away from threatening
| lawsuits over issues like this with well over a years
| worth of compensation just from a threat.
|
| This is separate from the moral issue - personally I've
| interviewed enough neuro-divergent candidates who were
| qualified (and hired a few) but who'd struggle with
| things like pairing and I'm personally not willing to
| refuse to make reasonable accommodations.
|
| > You're losing credibility with me. I've done exactly
| what GP is talking about and it was better than code
| reviews (etc), not worse. Are you talking from
| experience, or from personal preference?
|
| I'm talking from experience over nearly 3 decades,
| including direct personal experience in cleaning up the
| failures of teams who took short cuts because they
| thought pairing could replace code reviews. They catch
| different things. Pairing _for some_ teams where people
| are comfortable with it leads to lower counts of some
| types of defects assuming a lot of things go right (e.g.
| the pairs are matched well with people who 'll actually
| speak up and challenge each other), but pairs tends to
| look themselves blind to many of the same categories of
| failures as individual developers because they focus on
| solving a task and steer their view of the code
| accordingly rather than looking for at breaking it.
|
| It's the same reason developer written test suites does
| not obviate the need for QA, and internal security
| reviews does not obviate the need for external pen
| testers, or having developers try to think about
| operational issues does not remove the need for SRE's or
| equivalent.
| gregkerzhner wrote:
| The crux of it is that pairing works for some but not for
| others. But often, it's forced on everyone, usually from
| the top down. This is done in the name of vague benefits
| like "correctness" and "knowledge sharing". Have these
| benifits even been confirmed through unbiased scientific
| studies?
|
| The problem is that in the tech biz people tend to follow
| blindly without thinking. There was a point there where
| just because Pivotal Labs had some success pairing full
| time, everyone followed blindly. It's the same with
| leetcode style interviews, open offices and ping pong
| tables - it worked for google and all of the sudden
| everyone is following blindly.
|
| But personally, I wouldn't work somewhere which paired
| heavily even if the benefits could be proved. I simply
| won't do it because I don't enjoy it!
|
| Just like the choice to work remotely, the choice to not
| pair seems like a basic employee freedom that we should all
| have. Luckily, the way our industry is moving, such
| freedoms seem to be increasing.
| vidarh wrote:
| > Have these benifits even been confirmed through
| unbiased scientific studies?
|
| Good question. The problem there is that setting up a
| study of this is rife with problems. E.g. ensuring you're
| comparing "like for like" developers is hard enough. I
| have no problems believing that companies like Pivotal
| that are known to do it get good results from it, for
| example, because by announcing it they're self-selecting
| for developers who at least believe they do better in
| pairs. That may well even be a decent strategy to prevent
| dead-weights from applying, and so I could also very well
| see them doing better than a company with poor screening
| and performance management.
|
| > The problem is that in the tech biz people tend to
| follow blindly without thinking. There was a point there
| where just because Pivotal Labs had some success pairing
| full time, everyone followed blindly. It's the same with
| leetcode style interviews, open offices and ping pong
| tables - it worked for google and all of the sudden
| everyone is following blindly.
|
| Cargo-culting in other words...
|
| > But personally, I wouldn't work somewhere which paired
| heavily even if the benefits could be proved. I simply
| won't do it because I don't enjoy it!
|
| Same here. I'm fine with others doing it, including on
| teams I run, but other than sessions to _teach_ or
| _communicate_ a design I 'm unwilling to be forced into
| it.
| saulpw wrote:
| This are two modes, "explore" and "exploit". Solo thinking
| as you describe is usually best for exploring. Pairing is
| best for exploiting.
| vidarh wrote:
| Pairing doesn't work for me for either. It works fine in
| short bursts for knowledge sharing, but an understanding
| of a code base can be conveyed in small fractions of a
| time it takes to write it.
| pydry wrote:
| Mine is the exact opposite. Slowing down and explaining
| design firstly helps to clarify things in my own mind and
| the pairer will usually see things that I missed as I
| explain.
|
| I also find that getting stuck alone on a problem kicks me
| into a procrastination spiral whereas I tend to find it
| easier to push on when I'm stuck _with_ someone. It also
| helps prevent me from getting into a spiral of second
| guessing every technical decision ive made in the last
| month.
|
| I dont really think people take to pairing or not on the
| basis of its prima facie effectiveness though, but rather
| whether they enjoy programming as a solitary or social
| activity.
|
| Really, I think teams should be set up to ensure people who
| like pairing to be together and vice versa, coz i feel just
| as miserable working alone all day every day as you do
| pairing.
| vidarh wrote:
| > Mine is the exact opposite. Slowing down and explaining
| design firstly helps to clarify things in my own mind and
| the pairer will usually see things that I missed as I
| explain.
|
| I absolutely see value in explaining a design, and doing
| so with code, before you commit to the full project, but
| for me that step follows getting my initial design ideas
| down as code. I've had any number of projects where I've
| explained the high level design in words first, and
| people don't understand why it matters, and then I've put
| it down in code and shown the concrete benefits, and it
| instantly clicks. That doesn't mean that design will be
| set in stone and perfect, but I find it much easier to
| have the discussions about the design then.
|
| But that's me. If you prefer writing the initial code as
| well with someone, you should by all means keep doing
| that.
|
| > I dont really think people take to pairing or not on
| the basis of its prima facie effectiveness though, but
| rather whether they enjoy programming as a solitary or
| social activity.
|
| I think you're right, with a caveat that it's not for me
| necessarily about not enjoying social aspects of it, but
| about the _granularity of it_. I 'm happy to walk people
| through my code, but I want peace and quiet to put in
| place at least the outline of the design in solitude
| first.
|
| > Really, I think teams should be set up to ensure people
| who like pairing to be together and vice versa, coz i
| feel just as miserable working alone all day every day as
| you do pairing.
|
| That is absolutely reasonable. I have no issue with
| people pairing. I do have an issue with teams where
| becomes an expectation for everyone.
| almog wrote:
| Every word here.
|
| Pairing was highly encouraged in my previous job. We did it
| for 5 or so years, even when working remotely using tmux. In
| my last 2 years there, in an attempt to increase throughput /
| save time, pairing became something you only do for crucial
| task.
|
| I could argue that the code quality declined as well as the
| distribution of knowledge while not seeing significant
| increase in throughput of work done. Even more, and due to
| knowledge sharing, code review time increased.
|
| I recently asked a friend who's a team lead at a FAANG
| company if and how they do pair programming. His answer was
| that it is not encouraged, mostly because "performance
| reviews assess contribution of individuals, and pairing would
| disrupt this process".
| psysharp wrote:
| When a problem is new and fresh for each participant, pairing
| can be a great tool to connect with both the problem and each
| other's innate skillset, IMO.
| karmakaze wrote:
| Pairing doesn't have to be all or nothing. For tasks that
| clearly work better individually such as initial deep thought
| into an area, do that. For other tasks, getting in the habit of
| pairing has many secondary benefits that are only appreciated
| after doing it a lot for a while. Even after appreciating these
| benefits, it's far too easy in this age of remote work to
| ignore pairing, so it takes intentional action to maintain
| unless your team has already developed automatic pairing
| patterns.
|
| I especially like pairing with less senior devs that actually
| ask every question they think of. When I hear it, I try to
| pause and think what's this actually about and give as deep an
| answer as I can. Often this leads to discoveries that can
| simplify understanding, design and/or implementation. You get
| out of it what you put into it.
| kqr wrote:
| > 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.
|
| Are you against co-pilots in aircraft for the same reason?
| sgillen wrote:
| I think this is a false equivalence. If a programmer has a
| medical emergency during their working hours that's terrible
| but doesn't put others in danger.
| kqr wrote:
| A co-pilot isn't just useful for medical emergencies. They
| can double-check judgments, decisions, and plans as well.
| Because people sometimes interpret signals incorrectly or
| misunderstand contexts.
|
| That can happen to a programmer just as much as a pilot,
| and it can be even more destructive. You could argue
| software generally isn't life and death, but who knows? You
| might end up working on something like curl or sqlite which
| may well have played part in the implementation of
| emergency services in some country.
| jenscow wrote:
| That's what code reviews are for.
|
| Unless you're working directly on a live server.
| girafffe_i wrote:
| I've been trying to collect more sentiments on when people
| dislike pairing, and for what underlying reasons.
|
| Very curious to hear if you've thought about ego being apart of
| your position: if two minds can work through a design or
| implementation faster, but at the cost "I didn't get to figure
| this out myself" then you are prioritizing some personal puzzle
| solving pride over overall project efficacy.
|
| Maybe this doesn't matter working for"the man" but, if you
| started your own business and it's empirical that working with
| others helps solve problems faster, would you have a different
| position?
| ParetoOptimal wrote:
| > you are prioritizing some personal puzzle solving pride
| over overall project efficacy.
|
| Esteem and self-actualization are a part of maslows hierarchy
| of needs, I don't think this case is as simple as "pride".
| steelframe wrote:
| 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 wrote:
| 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 wrote:
| > 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_ wrote:
| 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
| skeletal88 wrote:
| 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 wrote:
| Which company do you work for?
|
| I researched pair programming companies a while back and didn't
| find any.
| skeletal88 wrote:
| 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]
| epgui wrote:
| CircleCI does a lot of pairing.
| calderwoodra wrote:
| Large consultancy, pair programs all the time, Java... I
| would guess Pivotal
| DLion wrote:
| Pivotal doesn't exist anymore. It has been acquired by
| Vmware and now it calls Tanzu Labs:
| https://tanzu.vmware.com/labs Btw there are many other
| companies where you can pair: Thoughtworks and Codurance
| for example
| samuelfekete wrote:
| > 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.
| brrrrrm wrote:
| 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 wrote:
| 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.
| lvspiff wrote:
| 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)
| kaonashi wrote:
| 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.
| okareaman wrote:
| 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.
| thrower123 wrote:
| 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 wrote:
| > 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?
| alexashka wrote:
| 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%.
| seanhunter wrote:
| I'm pretty convinced that pair programming is in and of itself an
| antipattern.
| Svetlitski wrote:
| 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 wrote:
| 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.
| codeflo wrote:
| "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.
| Icathian wrote:
| 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...
| vidarh wrote:
| 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 wrote:
| '"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
| number6 wrote:
| Using two input devices on one PC never occurred to me. Is it
| just plug and play or does it require some setup ?
| namibj wrote:
| 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).
| samatman wrote:
| 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.
| [deleted]
| Aeolun wrote:
| 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.
| danielovichdk wrote:
| 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
| donw wrote:
| 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 wrote:
| 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 wrote:
| 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[1]
| 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.
|
| [1] A university degree from an American university is now
| absolutely meaningless. Lots of organizations care about them
| as a pedigree check, but in terms of knowledge or capability,
| nope.
| Mountain_Skies wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-03-06 23:01 UTC)