I have two years experience pair programming, and to quote asthasr, I found it an absolute slog. I refrained from using anecdotal experience in lieu of research, but feel free to ask me anything about my experiences.
I have two years experience pair programming, and to quote asthasr, I found it an absolute slog. I refrained from using anecdotal experience in lieu of research, but feel free to ask me anything about my experiences.
To be honest, I can’t believe that anyone who advocates pair programming has ever actually pair programmed. It is a dismal slog—even when you’re lucky enough to get someone you like as a pair. If you don’t, then it probably could constitute torture.
It can be fun if you are lucky enough for it to feel like two friends trying to crack a puzzle, but when it is two people who barely like each other being forced to work together then it probably sucks.
I’ve had the experience you’re describing but the issue with “two friends trying to crack a puzzle” is that it actually requires a puzzle for the description to be applicable. For most professional, relatively experienced, developers, even if they are working on very interesting problems in the large, sitting at a keyboard isn’t really puzzle solving time.
If I have some problem that’s conceptually difficult I might talk to a colleague about it, but I don’t need them to spell out the solution or watch me do the same in implementation. Imagining pair programming as joint puzzle solving is a bit like considering a lawyer to spell checking a document for spelling mistakes the same thing as legal advice.
I’d also add that sometimes it is a way to get past a hurdle when you are banging your head against a wall. Not to be done every time, just when you are stuck and need extra input and a sanity check.
These scenarios aren’t pair programming, though. These are normal collaboration. Pair programming is supposed to be day-in, day-out shared-screen collaborative coding.
Well people rigidly following textbook definitions might be part of the issue.
Well, collaboration just happens. It’s a given. Every programmer who hits a snag collaborates (if they have teammates). Pair programming as a practice is different. If you’re not talking about the idea as espoused in XP or in Agile propaganda, you’re not really responding to it.
I see, I didn’t know they expected ALL code to be written that way.
Why are you talking about kicking a pig? That has nothing to do with anything.
I don’t understand what made you say this.
I wasn’t rigidly following the textbook definitions of the words in your sentence.
listen, if you don’t like pear programming then don’t do it.
I guess I disagree with you, and also disagree with the OP. While I would personally consider myself an advocate of pair programming as an occasionally useful tool, the OP certainly doesn’t consider me an advocate:
Certainly, I would not claim that. (In fact, I don’t think I’ve ever met anyone credible who has claimed something so rigid, so I wonder if the OP is engaged in a straw man.) What I would claim is that I have had the occasion to pair program with others (I have played both roles, the mentor and the mentee), and it has generally been a positive experience. I’d like to note though that it has always occurred under a mutual desire from both parties to actually pair program; I am certainly against some top-down force directing people into a certain style of work.
To give more context, I pair program very infrequently. It’s on the order of a few times (if that) per year.
I would also say that OP’s analysis seems quite incomplete to me. For example, the last time I pair-programmed with someone was on a bit of Javascript code. I know Javascript reasonably well, but the other person didn’t. We had a choice: I could either write the Javascript piece of the task, or the other person could write it. But the other person would take quite a bit longer because they’d have to learn a bit of Javascript to do it. However, in the future, it was clear that this other person would benefit from being able to make changes to the Javascript code, so perhaps the initial investment was worth it. Both of us saw this as opportunity to learn together. I hooked my keyboard into his computer, and we were off with a well defined task. He could ask questions and ponder things in real time, since my full focus was on the task. The exchange of information was rapid, and we both enjoyed it I think. Needless to say, that person has now made several other contributions to that Javascript code since then without any future pair programming.
Could that person have just picked up the Javascript themselves? Yes! Would it have taken them longer? Maybe. Would have it taken so long that it was actually worth me stopping all my work and pair programming for an hour? I have no clue. That kind of micromanagement of efficiency seems hard to nail down in a precise way.
Certainly the following Martin Fowler quote proclaiming that
Ep > Esmakes my argument not a straw man.Fowler also says this:
Which kind of puts a damper on this entire enterprise. This statement, to me, feels like it makes it clear that Fowler isn’t intending to be dogmatic about this. With that said, his choice of words could be better!
The statement you quote there certainly has the feel of something pragmatic, but in practice my experience with nearly everyone in the “agile world” has been a feverish dogmatism toward pair programming. I suspect it’s born out of a lack of empathy for others, and a failure to comprehend that a practice that might be overwhelmingly positive for them could simply fail to work for other teams, but whatever the reason the discourse has always been universally that pairing (or mobbing) is The One True Way, and any objections are purely the result of The Practice being misapplied.
Capital-A Agile usually means practices being dictated by one or two people (typically none of the four principles in the manifesto are noticed). Pairing in an environment like that is an exercise in management control by ensuring you are closely watched at all times.
Interesting. Thanks for sharing. I guess if this thread has taught me anything, it’s to be on the look out for places that mandate this style of pair programming and probably try to avoid them. I certainly have experience with “dogmatic agile,” but I hadn’t really heard of this intense style of forced pairing before!
And the next time I comment on this matter, I will be sure to get the definition problem out of the way first. :-) I had no idea that “pair programming” was even jargon in the first place!
My company does exactly that!
And good point about Martin Fowler.
Hmm… All right. Seems quite strange to me. I’ve never heard of such a thing! If that’s true, then yes, I agree that is quite unreasonable.
(I made a mess of my previous comment and edited it down to something more reasonable. Sorry about that.)
XP held that “all code sent into production is created by two people working together at a single computer.” Source here. With respect, I don’t think that if you only pair a “few times a year” you’re experiencing it as it works if executed as originally envisioned. Collaboration on hard problems is useful—even fun, if you’ve got a good colleague or two to work with. Pair programming, though, is not just that. It’s working on the same code, taking turns as the “driver” and the “observer,” either physically at the same computer or sharing your screen and microphone for hours every day.
Nobody bothered to actually define pair programming until now, but as this thread demonstrates, there is no obvious clear consensus on what the term means.
So if you say, “oh i was using this definition of pair programming. What do you think about that?” In response, i would say, “i wouldn’t want to work under those conditions either.” And indeed, i have never experienced that sort of pair programming.
In any case, i was clearly wrong about saying this post was a straw man, since it seems people really do advocate for this stuff. But I’ve never experienced anyone use pair programming with the definition you provided. At work, when we say, “pair program” we mean it as, “a short period of intense collaboration on the same code might be helpful.”
I think it has it’s place - for juniors or for the particularly tough problems.
That said, I’ve only really enjoyed it with a few people I call friends, generally never enjoyed it with anybody I didn’t get along with anyway.
I’ve always thought of it like being on a chain-gang, splitting rocks in the desert.
I thought the point of pair programming was not to increase efficiency, but to allow a junior programmer to understand how a senior works and improve their own skills.
This is incorrect. To quote from the Extreme Programming website:
An organization wanting to improve their junior developers through pairing will be very different from one that strives to practice pair programming proper. A few differences:
This is incorrect; look at u/gregnavis’s post.
Aside from that,
efficiency != efficacy. https://english.stackexchange.com/questions/50662/is-there-any-difference-in-meaning-between-efficacy-and-efficiencyYeah, I think that’s the way experienced coders need to understand it. At least since 2010, new coders have outnumbered us by at least 5 to 1. They will either learn on their own, the hard way, probably hurting your company’s viability in the process, or they will need good mentoring. For the few years I did pairing, it was really an excuse to get us to mentor, and not just write solo code all week. And I think in the long term, it was worth it in time/quality tradeoffs.
Since the sixties (as far as I’m aware), roughly half of programmers have had less than 5 years experience, with half the remainder having fewer than 10. That’s how fast people are entering the profession!
At work we’ve recently started using Architecture Decision Records (ADR). These are lightweight documents capturing a decision, and more importantly its context and tradeoffs. This has really cut down on rehashing conversations again and again, and lets us keep working asynchronously, while also transferring important architecture decisions.
I find ADR’s much easier to write than documentation, because you’re writing down what you’ve been thinking and talking about, rather than having to transform it into a documentation context.
Very cool to hear. Are any of them on open source or public projects? People are always looking for examples of ADRs they can study.
Unfortunately not, though I’ll probably use them on other open source projects I work on.
We pair program where I work (Capital One) quite often. I hate it. I don’t really pair very often because of it, but people always try to get me to do it. I can’t think straight when I have someone talking all the time. This is the second time I’ve done it. The first time was about 10 years ago and it was just as miserable.
Part of me thinks that people like doing it because it’s not as much work and you can goof around more. But maybe that’s just the cynical part of me.
That’s highly cultural; when I did it all the time it was much more work and much less goofing off. I found it very hard as I don’t enjoy talking that much either, and I avoid it as a rule, but I can’t say it doesn’t work.
[Comment removed by author]
That’s a nice writeup. There are probably many more important points that are not covered.
One that springs to mind is the trail of information left by code review, as long as all the communication is stored. On the bug tracker you find a first revision of a diff, discussion surrounding it, other revisions and changes.. that’s an incredible resource when you try to understand problems and decisions years down the line in a big, complex codebase. New developers can also learn a thing or two from these past discussions. Good luck finding that treasure trove of information in a pair-only project? Pairing is like an ad-hoc on-the-spot review, off the record.
I haven’t paired so maybe I’m missing something, but it sounds like debugging should be a major pain in the donkey. I might spend a day reading code, tracing execution, grepping, reading logs, etc. to understand and finally fix a problem. It can be very hectic going, constant jumping between files and windows, bookmarking things and taking notes that are probably inscrutable to anyone else. In the end, the fix might be a tiny diff. The last thing I’d want is having to constantly explain to someone else what I’m doing, during the process. That’d be a significant slowdown. And it would likely be very difficult for them to follow anyway.
It sounds very much like the “toolbox” point made in that writeup. Much of such bug hunting is all about gathering background information and (mental) whiteboarding of the system as it pertains to the bug.
I get the feeling that pairing might be better for small new code bases where the bulk of the work is just writing new code and nailing the design. In big, mature code bases there’s much more janitorial work that just doesn’t seem like it should benefit much from pairing.
So why not do best of both worlds? The junior developer doesn’t have to work all alone and in isolation until he’s made a complete diff. Perhaps they should, at one point, pair up for some time to discuss the direction, and then continue alone. Consult others when there’s a need for it. Sounds like traditional software development to me.
I spent a couple of years at a pair-all-the-time shop.
The trail of information gets replaced by an oral culture - because at least two (and often more) people were talking about it for long enough to make the decision, things got remembered (social interactions being easier to remember than written facts, for most). It was more lossy than writing, of course, but it was also very fast to access (minutes instead of days).
Debugging was slower for seniors; as a junior, I’d do the debugging whilst someone experienced would prod me to question assumptions and be methodical. As a result I learned debugging skills much earlier than I would’ve otherwise.
See, this is something I don’t believe can scale. Big projects will have too many details to remember for long. Nobody’s going to remember some things after years if they’ve been focused on something else for a long time. Heck they might not even be in house anymore.
I seriously doubt I’d get an answer in minutes if I ask about some tweak done in 2014, even if the right people were around.
OP here. I have 2 years of experience pair programming—we’re actually co-workers!
What I usually hear people say is that pairing is always slower but the resulting code is higher quality.
That said, pairing certainly only works when both parties are into it. If one brings their laptop or phone or just sort of dumbly watches then it goes very poorly.
Pair program takes “Hey, I need a second pair of eyes on this bug”, and elevates it to cult status. Doing that to any good idea will ruin it.
Pair programing is not about productivity. It’s about reducing the bus factor, spreading knowledge across the team and allowing junior developers to increase their skills.
My personal experience with a team who did full-time pairing was that, by the time I’d left, I had never in my life been part of a team where I understood less of the code or infrastructure. While I had exposure to large swaths of the system, the opportunity to actually dig in and grok the things was severely hampered by the pairing process. Combined with the cognitive overhead of constant pair switching (we pair switched between 1 and 8 times per day), and to simplify every single thought I had so it could be communicated verbally, there wasn’t the mental bandwidth left to think deeply about things even if I’d been allowed to derail my pair long enough to dig into something I hadn’t yet understood. I could see how people who are satisfied with a superficial understanding of things might be mislead into thinking that pairing reduces the bus factor, but I don’t think it’s actually the quality understanding that you’d want if people really did leave the team.
I had the same exact experience. Watching other people code is not how I learn.
Pair switched 8 times a day??
Madness.
There are other ways of reducing the bus factor without pair programming. The most obvious way is to let people work on more than one thing (not necessarily simultaneously).
There are others, sure - but as a method of spreading knowledge through a small group , 1:1 tutelage is pretty effective.
This is incorrect. See my comment above.
If we extend the definition of pair programming to mean a situation where two people work together then the discussion will become meaningless as it’s obvious that collaboration is required in many (most?) cases in all industries. What we’re discussing here is a specific programming technique that was first advocated by proponents of Extreme Programming. You can read more on the Extreme Programming website. A few quotes:
I’ve been pairing full time for five years. Having trained 12+ developers in that time, I can say with confidence that pairing is a unique skill that takes most people about 6-12 months to improve from “below average” to “above average”. I’d liken the difficulty to learning to touch type the first time.
Having put a lot of time into practicing the skill, right now I prefer to pair on most problems. I also prefer to use Vim, use TDD for most problems, and touch type. None are required to accomplish good work, but having the tool in the toolbox (with time invested to learn it) means I can judge for myself when the tool is appropriate to use.
Likewise, I’ve yet to see any believable research into programmer productivity. It’s currently impossible to measure, any studies are small sample sizes on the least possibly trained cohort (often times university students). As much as I want to believe in any study either way about TDD, pairing, static types, agile, new languages, etc, they are all just guesses made with anecdata and the fashion of the day. At least accepting the reality of the situation will let us tackle the real problem: why is programmer productivity impossible to measure?
I like better to work alone and then document the features I have implemented (with the whys and the hows I did that). However, recently I’ve been doing a bit of pair programming with a slightly-above-junior developer and her feedback was that she loved it.
I also found it very interesting because I’d reason more about the code before actually writing it and once I was done with the reasoning I would write some tests that would convey the thoughts we just had. Initially I was the only one actually using the keyboard and doing the talking while my co-worker was watching but after a while she started contributing with questions or solutions.
At the end of the day, it made me think of the PeepCode Play-by-Play screencasts where you’d see a high-profile open source developer tackle a problem and see what his or her workflow is. A lot of times it’s pretty cool as you learn a lot of things, from code tricks to editor shortcuts.