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

71–80 of 136 posts

Re: Pair Programming Antipatterns

#71

Post by [deleted] »

meken wrote: post #35
skeletal88 wrote: post #8

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

Which company do you work for? I researched pair programming companies a while back and didn’t find any.

[deleted]

Re: Pair Programming Antipatterns

#72

Post by karmakaze »

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…

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.

Re: Pair Programming Antipatterns

#73

Post by beebmam »

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…

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.

Re: Pair Programming Antipatterns

#75

Post by almog »

ryanbrunner wrote: post #26
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 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 we…

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

Re: Pair Programming Antipatterns

#76

Post by vidarh »

saulpw wrote: post #69
vidarh wrote: post #37

Earlier quoted context omitted.

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

This are two modes, "explore" and "exploit". Solo thinking as you describe is usually best for exploring. Pairing is best for exploiting.

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.

Re: Pair Programming Antipatterns

#77

Post by vidarh »

whynotminot wrote: post #64
vidarh wrote: post #37

Earlier quoted context omitted.

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

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

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

Re: Pair Programming Antipatterns

#78

Post by whynotminot »

vidarh wrote: post #77
whynotminot wrote: post #64

Earlier quoted context omitted.

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

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

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

Re: Pair Programming Antipatterns

#79

Post by vidarh »

pydry wrote: post #54
vidarh wrote: post #37

Earlier quoted context omitted.

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

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

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

Re: Pair Programming Antipatterns

#80

Post by jdlshore »

vidarh wrote: post #77
whynotminot wrote: post #64

Earlier quoted context omitted.

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

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

> 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?

Post reply on HN