In 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 suspect it's often done to make the weaklings appear productive.
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.
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.
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.
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.
I 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.
20 comments
[ 3.6 ms ] story [ 55.0 ms ] threadAnd the constant "No, no that line"... Ugh!
But maybe the "pair programming champions" are making yet another CRUD app
I'm waiting for the equivalent of Tesla's auto pilot for programming
https://twitter.com/devops_borat/status/300037586523676672
Not sure about your team lead, it doesn't match my experience.
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!
- ...
Documented code is a less expensive way to answer that question.
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.