Did anyone ever say it was?
Unfortunately, yes. The fad seems to have crested, but for a goodly while both Pair Programming and TDD were basically touted as cure-alls, by certain people.
Pair Programming Is Not a Panacea (2014)
11–20 of 21 posts
Re: Pair Programming Is Not a Panacea (2014)
#12In order for me to reach my highest level of productivity while programming, I need to be able to focus, and think, without interruptions or distractions. I simply cannot achieve that while having to interact constantly with some other person. IMO, there are occasions where pair programming makes sense, but those occasions are few and far between. To make it a standard, mandatory practice on a team is insane. I suspe…
'Pair Debugging' in my experience, is much more effective than Pair programming. And the constant "No, no that line"... Ugh!
Drives me nuts when the line numbers are turned off while pairing. That's the first thing I tell them to enable. Can't understand why that's a default for IDEs or people in general.
Re: Pair Programming Is Not a Panacea (2014)
#13Pair programming:
expert-expert:
- ya
- hu-hum...
- ya
- look... I'm way overloaded with work
- same here
- do you think we should both work on our stuff independently
- sure, It'll be more efficient this way, see you at lunch
expert-novice:
- but why are you assigning this?
- well, it's the counter and it has to start at zero
- well, shouldn't you use an accessor?
- an accessor for a counter?... (sigh)
- ya, we may want to change the counter to a float one day
- (silence) [adds the stupid accessor to have him shut up]
- and this should be a singleton
- (silence) [adds the stupid singleton with the ominous feeling of sinking deeper into depression, loosing any sense of passion]
- I was thinking, since we have an accessor for our counter, shouldn't we create a factory to automate instanciation too?
- [leaves for a cigarette break and never comes back... to this day, the whereabouts of this pragmatic programmer is unknown]
novice-novice:
- Let's make an accessor!
- Yeah! and let's make a singleton!
- Yeah! and a factory? (honhonhon) [it's a french dude]
- Sure! and maybe we should have a red-black tree of factories, imagine the power!
- Woooaa! I can't fathom the power! I never heard of such a thing!... it's AWESOME! ... Maybe we should template all of this
- you're reading my mind!
- ...
Re: Pair Programming Is Not a Panacea (2014)
#14Pair programming really only answers the question: "How can I make sure my programmer's death/departure doesn't stall the project?"
Documented code is a less expensive way to answer that question.
Re: Pair Programming Is Not a Panacea (2014)
#15Did anyone ever say it was?
I'm the author of the blog post and I now see I didn't make the context clear enough. I wrote that post after leaving a company that 100% pair programmed all the time. I'll update the blog post next time I get a chance.
Do you find that your programming habits are altered after having programmed in that configuration for a time? I ask this because the only other programmer (the team lead at my current company) I've known who did pair programming seems to be "stuck" in that mode. He can only work with one other programmer on a single project. It feel it makes him a terrible team lead.
Re: Pair Programming Is Not a Panacea (2014)
#16Earlier quoted context omitted.
I'm the author of the blog post and I now see I didn't make the context clear enough. I wrote that post after leaving a company that 100% pair programmed all the time. I'll update the blog post next time I get a chance.
Do you find that your programming habits are altered after having programmed in that configuration for a time? I ask this because the only other programmer (the team lead at my current company) I've known who did pair programming seems to be "stuck" in that mode. He can only work with one other programmer on a single project. It feel it makes him a terrible team lead.
I really hate pair programming, so I've very easily switched away from it. With that said, even with my hatred for it I can recognize when it has value. We never pair program at my current job, and the truth is there are times we should.
Not sure about your team lead, it doesn't match my experience.
Re: Pair Programming Is Not a Panacea (2014)
#17I'm a fan of side by side programming.
This is where both people have their own computer. Both work on quasi-independent problems, but are free to ask the other questions and bounce ideas off them. Basically, stay far enough away in the code to not create to many merge conflicts, but close enough that you both can keep a mental model of your work and the others work.
I prefer to share a whiteboard rather than a keyboard.
Re: Pair Programming Is Not a Panacea (2014)
#18Pair programming: expert-expert: - ya - hu-hum... - ya - look... I'm way overloaded with work - same here - do you think we should both work on our stuff independently - sure, It'll be more efficient this way, see you at lunch expert-novice: - but why are you assigning this? - well, it's the counter and it has to start at zero - well, shouldn't you use an accessor? - an accessor for a counter?... (sigh) - ya, we may…
expert-novice: funny, but the expert is not doing the job. You're there to teach. If you're not going to, why bother?
Re: Pair Programming Is Not a Panacea (2014)
#19Pair programming really only answers the question: "How can I make sure my programmer's death/departure doesn't stall the project?" Documented code is a less expensive way to answer that question.
well documented code is hard to come by- I only encounterd it once- an then only in an lib where the API was well documented.
Re: Pair Programming Is Not a Panacea (2014)
#20I found pair programming great, when another developer and I were architecting the foundations of business app. After that we were able to split of portions of the app such as various worksheets type pages, to ourselves and junior developers pretty easily.