Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pair Programming Antipatterns

tuple.app

Post reply on HN
Print view View original

41–50 of 136 posts

Re: Pair Programming Antipatterns

#41

Post by vidarh »

codeflo wrote: post #27

“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.

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.

Re: Pair Programming Antipatterns

#42

Post by DonHopkins »

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!

Re: Pair Programming Antipatterns

#43

Post by dimmke »

gregkerzhner wrote: post #7

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 (ju…

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.

Re: Pair Programming Antipatterns

#44

Post by wowokay »

gregkerzhner wrote: post #7

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 (ju…

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.

Re: Pair Programming Antipatterns

#45

Post by brandall10 »

jatins wrote: post #15
gregkerzhner wrote: post #7

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 (ju…

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 a…

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.

Re: Pair Programming Antipatterns

#46

Post by girafffe_i »

gregkerzhner wrote: post #7

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 (ju…

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?

Re: Pair Programming Antipatterns

#47

Post by davidmurdoch »

codeflo wrote: post #27

“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.

'“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

Re: Pair Programming Antipatterns

#48

Post by Icathian »

Abroszka wrote: post #29

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.

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.

Re: Pair Programming Antipatterns

#49

Post by Icathian »

codeflo wrote: post #27

“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.

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...
Post reply on HN