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

91–100 of 136 posts

Re: Pair Programming Antipatterns

#91

Post by jdlshore »

Mountain_Skies wrote: post #39

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…

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.

Re: Pair Programming Antipatterns

#92

Post by vidarh »

gregkerzhner wrote: post #65
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…

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…

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

Re: Pair Programming Antipatterns

#93

Post by seanhunter »

Svetlitski wrote: post #87
seanhunter wrote: post #84

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

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…

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.

Re: Pair Programming Antipatterns

#94

Post by whynotminot »

vidarh wrote: post #88
whynotminot wrote: post #85

Earlier quoted context omitted.

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

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

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

Re: Pair Programming Antipatterns

#95

Post by Izkata »

ryanmcgarvey wrote: post #66

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

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.

Re: Pair Programming Antipatterns

#96

Post by danielovichdk »

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

Re: Pair Programming Antipatterns

#97

Post by vidarh »

whynotminot wrote: post #94
vidarh wrote: post #88

Earlier quoted context omitted.

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

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

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

Re: Pair Programming Antipatterns

#98

Post by thrower123 »

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.

Re: Pair Programming Antipatterns

#99

Post by moron4hire »

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…

Nah, it's about management weaponizing coworkers against each other to make sure nobody is "goofing off".

Re: Pair Programming Antipatterns

#100

Post by slaymaker1907 »

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…

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