Pair Programming

Published by Manton Reece (@manton) — RSS Feed | Export CSV | Embed

Someone finally articulated exactly why I find Agile & Pair Programming so uncomfortable: http://bit.ly/hdNOvH /via @marcprecipice
@buzz If Agile was the Bible, Pair Programming would be the bit where Jesus does mean stuff. It's the bit that followers tend to skip over.
@buzz It's an introverts worst nightmare. No "down" time to think, stare into space, and recharge your batteries. It's an extroverts dream
@haseman I think that's accurate. Most of the people I know who are super into pairing are young, highly social, extroverted people.
@buzz I like paring for tough domain-knowledge shared problems but mandating it is like forcing a house Contractor to use only screwdrivers
@wooster Remember Jobs' quote about a small team of A players running circles around a giant team of B players? Pairing optimizes for B.
@buzz I find "collaborative problem solving" (especially using a whiteboard) far more commonly beneficial than "pair programming" personally
Pair programming. Now you've got two problems.
@buzz @wooster @wisequark I've found the only useful pairing sessions start with the words "I cannot figure this out"
@buzz how so? #honestquestion — I like the claim, but how would you back it up?
@janl My opinion (and this will severely piss people off): pairing is designed to optimize the output of programmers of varying ability.
@janl In that sense, it's probably successful. In my opinion, though, it can hold back the best, most creative engineers.
@buzz slow & predictably quantifiable progress makes PMs happy. Easier to predict bullshit dates.
@janl Agile's jargon ("cowboy coding," etc.) seems to me to be rife with distrust for programmers and disdain for individual contribution.
@rtmfd It's no accident that Agile was created by people who bill by the hour.
@buzz that's because most managers prefer fungible programming units to individual contributors.
@buzz Indeed. I think most software dev processes are optimized for getting the most out of a team of mediocre devs.
@cbarrett I feel like I'm turning into the Ayn Rand of software engineering here.
@buzz One thing I really like about "agile" methodology is the notion of always-shippable-software. It's a useful design ambition, IMHO.
So glad I work alone and don't have to worry with pair programming, agile or any other Hacker News humping kool-aid.
@buzz I've done full-blown "extreme programming" based projects with great success. You can't, though, just adopt part of the methodology.
@buzz The worst software disasters I've seen (cleaned up after) were "agile" teams that only adopted part of some methodology. Trainwreck.
@danielpunkass I 100% agree with that philosophy. I am totally a fan of continuous integration.
@bbum I respect your opinion, and I'm sure it works well for some personalities and some projects. I'm pretty sure it's not for me though.
@buzz @janl "Agile" is a bunch of hostile philosophies. XP lets individuals do spikes, but code review & tests make it safe for checkin.
@buzz Nope -- you are pretty firmly in the "Cowboy Programmer" camp & any decent manager/employer wouldn't put you in that situation. ;)
@buzz @janl XP planning game is all about letting devs negotiate what they can do instead of a manager making up fairy tale plans.
@buzz @bbum I've had great (and some not-so-great) experiences with XP, and I use much of it daily. Just not much pairing anymore.
@buzz I could not disagree more. Pairing has nothing to do with compensating for mediocre programmers. A + A = A+
@al3x What's your take on its benefit?
@buzz Uh, two smart people working together produces higher-quality software in less time? You gotta have a productive pairing, though.
@buzz Not every programmer is suited to pair with every other programmer. But that doesn't mean pairing is broken as a process.
@al3x Isn't it possible that it simply doesn't fit some peoples' work styles and personalities though?
@buzz I think those people need to get over their shit, basically. The end product and knowledge sharing is worth it.
@buzz That said, I think there are particular parts of the development process that better suit solo coding. Prototyping, for example.
@buzz I just think that, if all possible, code that goes into production or to end users should be paired on, or at the very least reviewed.
@al3x On the iOS at Square, everything merged to master is reviewed. I totally support that, and even like it due to the knowledge exchange.
@al3x I'm also not against sitting down with someone to work on a problem. What I dislike is institutionalized pairing, a la Agile.
@al3x I also support the idea of continuous integration, and keeping things shippable (esp. after working on some out of control projects).
@mrgan @al3x @buzz This is obviously a style/personality issue. Alex's "productive pairing" requires two people who are into paired labor.
@cbarrett That's exactly how I've always felt while pairing.
@al3x @buzz Unit tests are the introvert's pair programming.
@buzz @manton A thought that occurred while reading that: code review/testing are essential, but pairing/TDD are simply one way to do those
@pilky @manton Yeah, I think that's an important point. I'm a believer in code review, I just find "joined at the hip" pairing problematic.
@buzz @pilky Makes sense to me too. Good to have a sanity check or to brainstorm, but my more creative work is usually in focused isolation.