Hacker News new | ask | show | jobs
by BurningFrog 2300 days ago
> How do we reconcile it with another popular argument...

I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)

I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.

Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!

I've never learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.

You're right that the restricted schedules are a downside.
1 comments
Silhouette 2300 days ago
I've literally never worked for any employer in any development role where spontaneous pairing or larger group collaborations didn't happen often. It's just human nature. I see others commenting in this very discussion with similar anecdotal experience, so apparently I'm not just completely weird in this respect.

I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.

link
BurningFrog 2299 days ago
We may just mean different things by pairing.

Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing

link
Silhouette 2299 days ago
Just to be clear, I'm talking about two (or more) developers, gathering together to solve a problem collaboratively, with the end result that the code to do so is written or at least the significant questions have been answered and what remains is little more than a mechanical exercise. But I'm talking about that happening spontaneously, and not necessarily starting from a complete blank slate, being done on a specific schedule or according to any specific process or using any specific tools, or being required as formal policy.
link