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

61–70 of 136 posts

Re: Pair Programming Antipatterns

#61

Post by Mezzie »

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

Re: Pair Programming Antipatterns

#62

Post by brrrrrm »

samuelfekete wrote: post #9

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

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

Re: Pair Programming Antipatterns

#63

Post by coryrc »

soneca wrote: post #25
jatins wrote: post #15

Earlier quoted context omitted.

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…

If they are pairing to do high level design, then you are not disagreeing with GP

I was just looking at their changes recently, plenty of regular improvements to code.

Re: Pair Programming Antipatterns

#64

Post by whynotminot »

vidarh wrote: post #37
ryanbrunner wrote: post #26

Earlier quoted context omitted.

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

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

Re: Pair Programming Antipatterns

#65

Post by gregkerzhner »

vidarh wrote: post #37
ryanbrunner wrote: post #26

Earlier quoted context omitted.

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

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…

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.

Re: Pair Programming Antipatterns

#66

Post by ryanmcgarvey »

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

Re: Pair Programming Antipatterns

#67

Post by sidlls »

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…

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

Re: Pair Programming Antipatterns

#68

Post by nkingsy »

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

Re: Pair Programming Antipatterns

#69

Post by saulpw »

vidarh wrote: post #37
ryanbrunner wrote: post #26

Earlier quoted context omitted.

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

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.

Re: Pair Programming Antipatterns

#70

Post by skeletal88 »

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.

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