Pair Programming - My Personal Nightmare

(83 comments)

June 11th 2013

Since the dawn of XP, I've read about the benefits of Pair Programming. Evangelists have told us that it will improve code quality, help knowledge dissemination, and even boost productivity, all while cultivating deep, soulful bonds between developers (see: spooning).

Those who reject pair programming are assumed to be cowboys, slackers, or social recluses. Well, I'm none of these (at least I don't think), but yet I still hate the idea of Pair Programming. For what it's worth, here's why...

We are no longer a culture that respects silence. The extroverts have won. Everything must be done collaboratively. Everyone must be available to everyone, all the time. There should be no more personal space, and no ownership of work. Basically, we believe that two heads are always better than one.

And yet it should be obvious to us that this is not always the case. Just in the world of programming, some great works of innovation and craftsmanship have sprung not from a team or a pair, but from the efforts of one person. I think about Ant, a huge leap forward for the Java community at the time, developed by one guy on a flight from Europe to the US (1). Or a tad more current, consider Notch of Minecraft, Marco Arment of Instapaper, or Gabriel Weinberg of DuckDuckGo: all solo achievements (2). In fact, one of the most influential programmers (if not people) in the world, Steve Wozniak, famously advocates:

"Work alone. Not on a committee. Not on a team."

Going further, some of the greatest thinkers in science and art are of the heads-down (i.e. introvert) variety - think Darwin, Einstein, Newton, or heck, even Dr. Seuss (3). Even John Steinbeck chips in here:

Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy. Once the miracle of creation has taken place, the group can build and extend it, but the group never invents anything. The preciousness lies in the lonely mind of a man. (4)

Ok, I'm waxing philosophic here, but back to our own little corner of the world, software development, why would we believe, as some argue, that hyper-collaboration (e.g. pair programming) is a precondition to quality or productivity when we can readily think of so many counterfactuals? Why, for some, is Pair Programming a "must do", all the time?

I believe it's just a reflection of one's own personal psychology. Simply: some people enjoy this style of work, and so they prescribe it, vociferously, for everyone.

The truth is, however, that one third of us are introverts (and probably more for programmers!). In general, we not only prefer but thrive when working in solitude. It's not that we don't like people, it's that our brains are wired to be more disrupted by stimulation (and, for good or bad, this includes pairing). For us, doing quality work is about getting and staying in "the zone". When we do, we're highly productive. When we don't, we flail.

Demarco and Lister, in their famous Coding War Games experiment, demonstrated just this - the best predictor of quality for programmers, they found, was not years of experience or salary but rather how quiet their office environment was.

This used to be a respected insight. In fact, #8 on the Joel on Software Test of good places to work is "Do programmers have quiet working conditions?" Sadly, however, the culture of hyper-collaboration has rolled over our better sensibilities, and to be perfectly honest, I think it kind of sucks.

Pair Programming, an extension of this "everything-together" culture, has permeated our thinking to the extent that many think that one person working in isolation is not just ineffective, but boring to boot. For me, it's the opposite. My best work is done in solitude, and the state of flow is what I enjoy most about being a programmer. It's not about being a "cowboy", or thinking I'm above mistakes. I'm a huge advocate of rigorous code reviews, and I benefit daily from the insights of others. It's just that the hyper-collaborative state of pair programming doesn't make me a better (or happier) programmer. Please take my word for it.

When people describe pair programming as a practice that they benefit from, cool, I get that. But when they take the next leap and advocate (or mandate) the practice for me, because they "know" I'll benefit from it (and have "data" to prove it!), slow down. The methods by which people produce quality work are as varied as we are. Consider some great achievements in the world (or just on your project!) and this should be obvious. To claim that this extrovert's ideal of pair programming is a "best practice" for all is foolish, I don't care what the agile dogmatists say.

References

Ant: The Definitive Guide, Steve Holzner
Pair Programming considered harmful?, John Evans
Quiet: The Power of Introverts in a World That Can't Stop Talking, Susan Cain
East of Eden, John Steinbeck

Recent Posts

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.

I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!

Got a Comment?

Comments (83)

12 Year Developer

June 11, 2013

I've worked most of my 12 year professional career as a solo developer. Over the last two years, I have done some pair programming. I've found that there are situations where pair programming is really good and there are situations where it is terrible -- and the situations are more dependent on the type of code being written rather than the personalities of the developers.

Pair programming has been beneficial when two developers are both not experts on a particular function and are dealing with rather complex logic. It is also beneficial for training (when the code is unfamiliar with the particulars of a module/library/etc...).

Solo programming is better when a domain expert needs to power through something. (I recommend that the code be reviewed afterwards to make sure the code is still clear and isn't too far above other people's heads, but pair programming can slow down a domain expert which can be detrimental to a schedule.) In my experience, solo programming is also best for grunt work, most types of debugging, etc....

Ryan

June 11, 2013

Sorry Steinbeck but: Marr and Moressy > Marr, Moressy

I think the thing to keep in mind is that people are different, work differently, and different problems can be solved better by different approaches.

Anytime a person gets all "I'm a hammer all I see is nails" it's probably not a good thing.

Kevin Clark

June 11, 2013

I've been employed as a software engineer for 20 years. I agree with everything you wrote here.

There have been some jobs I've worked at where I would have welcomed some pair-programming at the start of the project (to get myself familiar with an un-documented, un-designed codeset), but, beyond this, I've always done my best work by working alone. Like you, I welcome collaborating with my co-workers through things like design-reviews or code-reviews, etc.

(and...since we're on the subject, I seem to perform a lot more of these sorts of formalized information-sharing sorts of things than many of the people I've ever worked with over the years)

But...the idea of sitting in front of a single computer with another person doing programming work seems like a bad idea to me. I did this a few times during my undergrad days and it was always stressful and didn't seem to yield good results.

Ray

June 11, 2013

Just to say, you're point is well taken, it definitely seems up to the personalities involved. I've known programmers who have paired diligently for years after which they firmly said "I never want to do that again".

You'll want to be careful about subjective opinion, though. Pairing, like TDD or refactoring, is a skill that is practiced over time. You may find that reading about it or trying it a few times simply isn't enough to garner an appreciation for the skill, especially if the other programmer you're pairing with is at a similar level of experience.

Darth Continent

June 11, 2013

Agreed with 12 Year Developer, their comment captures my take on pair programming.

Of course, if you're ever in a situation where some cheerleader-style extravert project manager or team lead tries to hamstring you into pair programming against your will, you should come out of your shell and PUSH BACK.

That way you get it off your chest, and the resentment of having to go against your flow won't insinuate itself into your work and make you feel lousy about having to get up to go to work in the morning.

Andrew

June 11, 2013

The main benefit of pair programming is not code quality. It's organizational stability. If your whole dev team pair programs 100% of the time, half of them can get hit by a bus and you won't miss next quarter's numbers.

Newbie

June 11, 2013

I very much agree with everything you just pointed out. I'm currently studying to become a developer (just started out with python, javascript etc.) and what really baffles me about my education is that out professors expect us to write code in pairs. Why? I cannot wrap my head around that teachers, that themself are programmers, think it would be a good idea for all of us to work in pairs. Personally I work much better alone. Alone I get a chans to work myself through a problem and not have a person sitting next to me just telling me whats wrong (or if the scenario is the other way around, that I have to help the other person understand that's going on).

The point I want to make is that even if you're just learning the basics of programming, or if you work in developing, at least you should have enough freedom to chose yourself if you want to work in pairs or alone. Everyone is different and beeing a lone wolf is not wrong.

lolocaust

June 11, 2013

"There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy."

what a crock of shit

Bill

June 11, 2013

Wouldn't the world as a whole be improved if we actually tried stuff before forming an opinion on said stuff? Maybe I missed the bit where you said you had tried pairing.

I've worked in both pair and non-pair environments, including a year where I was expected to be pairing all the time. It's hard, and I don't feel like I ever got really good at it, and I'm sure it's not for everyone.

But man: the times when it was really clicking? Some of the best times of my life, where I produced the work I'm (so far) most proud of.

Also: the volume thing. The office environment where I (and two other pairs) worked side-by-side was (so far) the quietest and most work-conducive environment I've worked in. "Loud" does not follow from "pairing." "Sit close and collaborate" doesn't necessarily mean "distracting levels of noise."

Nico

June 11, 2013

Glad I'm not the only one who thinks like this

TheCrittaC

June 11, 2013

I agree wholeheartedly with what you write, based on programming exercises/projects in my computer science courses. However, my experience with the small free software IRC bot that I maintain has shown otherwise. This could be due to other developers and I rarely working on the exact same piece of code, or working on the bot at the same time.

Mei

June 11, 2013

Wasn't Steinbeck born *after* the Wright brothers? ;-)

Great article.

Andrew Mortimer

June 11, 2013

There's a typo in the eighth paragraph (excluding block quotes as paragraphs.) are/our

Good read otherwise. Thanks.

Ben

June 11, 2013

Thanks for all the comments!

@12 Year Developer - Great points. In the end, I agree that PP is probably context specific. There are times where I'm sure it's valuable, and there are personalities for whom it is more/less helpful. I just don't buy the dogma that some espouse that it's always good, for everyone.

@Bill, @Ray - I probably should've made it more clear that I have tried pair programming. It just doesn't jive with how I think or how I work. Agreed that "loud does not follow from pairing", but for me, the very act of conversing with someone about what I'm doing at all times is distracting, and kind of annoying to be honest.

@Kevin Clarke - Thanks!

@Mei, lolocaust - Haha. I just threw in the Steinbeck quote in to stir the pot. Obviously there are plenty of instances where collaboration works. The greater point I was making was that the opposite is true too. Much has been produced "from the lonely mind of man".

@Newbie - Wow. I thought PP was more of an industry thing. It's frustrating that people (and professors, apparently), assume this is an effective approach for everyone. As a student, I would want some leeway to explore things as I programmed...to go down false paths...to make mistakes...but I probably wouldn't do these things if someone was sitting right next to me.

@Andrew - Excellent point, and I should have mentioned this. I'd hope that organizational stability can be achieved at a lower cost, for instance through code reviews, or switching domains after every sprint.

Roshan

June 11, 2013

http://www.amazon.com/Quiet-Power-Introverts-World-Talking/dp/0307352153

As everything in life, an organization needs diversity to succeed and thrive.
Some people, Some projects thrive in pair-programming / teams.
Some people and Some projects thrive in solo.

The worst thing you can do is force people to do the other thing.

Gordon Morehouse

June 11, 2013

I'm mildly introverted, and working in a rotating pair/dyad with another mild introvert and a deep introvert, all of us grew a great deal in many ways.

This has little to do with introversion/extroversion. If you don't like it, you don't like it, but don't try to deconstruct it with glasses tinted with a color quite similar to evolutionary psychology.

David Barri

June 11, 2013

Good piece. I agree. It's nice to see that the voice of reason is slowly starting to make a comeback into our industry.

mr. fancy pants

June 11, 2013

It's patently false that many of those worked alone. Einstein was known to have received significant help with the mathematics on the theory of general relativity.

matt korwel

June 11, 2013

I would agree that having things mandated is no fun. Dogma for the sake of dogma is not often practical effective.

But to be sure that you can only be effective one way feels like you are determined to miss some good opportunities.

If my experience, when someone has a really adverse reaction to pairing it's a reaction to a bad pair or to having it mandated, rather than to pairing itself. Can you describe a bad outcome you had while paring? What kind of pain did you feel?

Check out: http://www.asynchrony.com/2012/06/7-habits-of-highly-effective-pair-programmers/ - It's really an Art, working together in a way that works for both people. That takes practice and dedication.

The reasons to put in the practice and dedication to build a working pair relationship are not limited to "quality or productivity". I'm sure you've seen this or similar articles https://www.braintreepayments.com/braintrust/code-quality-is-the-least-important-reason-to-pair-program but there really is a lot more to it.

Simbosan

June 11, 2013

Amen, oh God, amen. Professional managers who use the word 'team' too much have taken over the asylum. I don't think it's necessarily extrovert vs introvert as 'political' vs 'task focussed'

Jaideep

June 11, 2013

So true . Problem with the whole thing is that extroverts usually never really understand an introvert's problem. They usually thing that everyone is like them.

Being an introvert I don't mind pair programming as such when its done to a lesser extent only , but when its forced all the time I often feel suffocated , dissatisfied and demotivated.

If you are an introvert you can understand this but an extrovert usually won't .

Maxxx

June 11, 2013

Surely a big point of PP is that mistakes are far less likely to be made with two pairs of eyes - and issues about exactly how to solve the problem at hand can be immediately discussed.

Much rubbish code is produced by individual devs, for any number of reasons (trying the latest technique for fun, rushing to finish and can't be bothered, just a rubbish dev, whatever) which will be tempered if not stopped by pair programming.

Sure, any technique can be done badly without the full participation of the players (you should attend some of our Scrum meetings!) but I reckon if you put away your prejudices, opened your mind, and gave it a go with a positive attitude, you would be surprised at how effective it can be,

I first started PP in a software house in the UK in the 80's - the software my team produced was the most bug free and easily maintained that we had ever produced.

Sure, I had to wade in and separate a couple of the devs when it came to fisticuffs over the use of a particular method - but even that was far more effective than the situation where two devs silently and secretively undo one another's code !

david karapetyan

June 11, 2013

One of your quotes is almost entirely false. There have been great duos in all branches of human endeavor. You only have to do a cursory search to find all sorts of theorems named after two mathematicians, not because the theorem was discovered independently by each, but because it was a collaborative effort. Some links: The Hardy-Littlewood axioms of collaboration: http://www.math.ufl.edu/misc/hlrules.html, Atiyah-Singer index theorem: https://en.wikipedia.org/wiki/Atiyah-Singer_index_theorem, Collaboration in mathematics: https://cameroncounts.wordpress.com/2009/10/28/collaboration-in-mathematics/.

Dennis

June 11, 2013

Hey guys,
here's my ongoing experience with pair programming.
I think people work in different ways and different speeds.
Whenever i have to do pair programming i notice that all the time.
In the last year i had to do pair programming on a regular basis with both introverts and extreme extroverts. Me being an introvert, working with a person that blurts out every little idea that comes to their mind is extremely hindering, since it disrupts my thinking constantly. It keeps shoving little very unshaped and very unfinished and sometimes plain wrong ideas into my thought process and often times straight leads me down the wrong path, before figuring that out and talking to said person.
It can be quite frustrating.
When the right pair exists, it can be extremely productive, though.
I think pair programming is a good thing, but having to find the right pair makes it a less good thing.
You also have tons of developers that write really shitty code when you let them work alone. So some people actually need pair programming to produce good results...

Ulf Andersson

June 12, 2013

Not a very new subject.

“Distraction is the only thing that consoles us for our miseries, and yet it is itself the greatest of our miseries.”

Thoughts - section II, paragraph 171, The Misery of Man Without God
Blaise Pascal 1623 - 1662

Ripped out of its context. But the work is full of little nuggets that may need quiet contemplation. YMMV.

By the way, I have in my career since 1982 seen and felt all variations from working alone in quiet solitude, to working in a noisy lansdcape close to a lab area full of noisy equipment. I know what I prefer. Again YMMV.

Ilja Preuß

June 12, 2013

The strongest pair programming proponent I ever worked with was also the most introvert person I ever encountered. So much for that excuse to not try Pair Programming. (He was also very reluctant to try it, at first.)

daniel

June 12, 2013

I Agree

Pair Programming = low quality system

The car industry found this out in the 1920's

http://en.wikipedia.org/wiki/Scientific_management

that's the problem with the people who designed XP/Scrum is they don't have a background in Organisational Psychology - only focused on technology and systems - it's people who write software

One of my interview questions is - do you use pair programming - if yes, i thank them for their time and leave.

Martin Griffiths

June 12, 2013

I've pair programmed quite a bit in our team and for us it works best at the beginning of a project when you can make important technology choices and do a lot of the sanity checking early on. In this situation I think it can save loads of time especially if you're prototyping initially, bouncing ideas off one another can be engaging and very rewarding.

Once you get into the main body of the project and it's heads down time, you can go back to working alone.

We've proved this to be successful and not at all stressful or time wasting.

AmightyWind

June 12, 2013

Pair Programming is Bull$hit. ...There I said it.

Francis W. Porretto

June 12, 2013

In over forty (yes, forty) years in software, I have never encountered a situation where compelling two people to execute a task that could be done by one worked out for the better. But I have seen "committee development" schemes -- and remember, "two" is merely the smallest possible committee -- crash and burn several times. The common factor in those disasters was the dilution of the sense of responsibility for the product: virtually no one felt it was in any way his job to make sure things worked, met applicable constraints, were adequately documented, and so forth.

There are ways to armor a company against the possibility of loss of domain or product expertise that are far less intrusive than "pair programming." Inasmuch as it deprives the employer of as much as 50% of the productivity potential of his team, I expect that this fad, like so many others, will have its day in the sun, and then fade quietly away.

anemet

June 12, 2013

Brian Kernighan used to work a lot in pair-programming when he developed Unix or something like that in C, and as I understood, he didn't type, but was able to mostly debug the code mentally and figure out the problem before actually running the debugger :) I guess it depends on the programmer.

Chris

June 12, 2013

Amen! Thanks for saying what I've intuitively known for some time.

charlesprogrammr

June 12, 2013

I wholeheartedly agree. Long live the INTJs and the INTPs!

sakamoto

June 12, 2013

Thank you for writing this. Articulates much of my thoughts on the matter.

Blogging Molly

June 12, 2013

I work in an environment where pair programming is the norm. Most of the time, it is getting one for the price of two (or three). There is a pairing area in which there are typically numerous pairs working. Those conversations, with the addition of maybe a scrum meeting going on in the adjacent space, create a work environment in one cannot hear oneself think.

I see the application of pair programming as a teaching tool only. Learn what you need to learn, then go off and be productive. Most of the time, pair programming is just a slow motion code review. During research on how to accomplish a task, pair programming simply cuts productivity in two.

Pair programming is no substitute for good design, and good design seems to be contrary to the goals of agile incremental development.

Veg

June 12, 2013

Thank you. I'm so glad it's not just me.

Url Onz

June 12, 2013

I will live under a bridge and pick through dumpsters before I will pair code.
At one time I had a 30 minute turnaround time on bug and data fixes. Now it takes two or more weeks to even get permissions to start the job. That because I now work for (As Odin is my witness) never with a team. Teams are hiding places for the unskilled and inept.

Eddie

June 12, 2013

This. Thank you for writing up what I have thought so often. I couldn't agree more. For me, I enjoy collaboration when working out architectures or various approaches to a problem. But once it's known what needs to be done and it gets down to coding, I most often need to work alone. It's like having a back seat driver and frankly, it makes me nervous (and I'm hardly a newbie - I've been a professional developer for 17 years, and taught programming and electronics for 6 years before that). I can't even type effectively with someone else around.

It also depends a lot on who I'm pairing with. I worked with one guy who is a big advocate of pairing, but he's terrible to pair with (at least for me). If he's "driving" I'd just sit and watch because he didn't really want to listen to any suggestions, and if I was at the keyboard he pretty much wanted to dictate everything. I'm pretty mild-mannered so I'd just go along and humor him regardless of whether I agreed with him or not. And that's NOT how pair programming is supposed to work.

Bruce Patin

June 12, 2013

I taught programming for over 10 years and consider myself an introvert (INFP). Teaching was exhausting and I needed to be alone quite a while to recuperate. One reason teachers might tend to advocate pair programming is that they must have some extroversion or they couldn't teach and they got used to programming in front of 20 people asking questions as they go. Another reason is that they usually have introduced concepts that they expect their students to use without much deeper thought than what the teacher has taught. Two students together in that situation can usually help each other out, if one or both of them didn't quite grok the concept.

However, in practical work, I often need to spend some time alone deep in thought manipulating data structures and methods around in my head until I find something elegant that satisifies all of the requirements and can be easily extended in case the requirements change. Sometimes I need to type fragments of the code I am thinking about in order to see it better. Trying to do that all of the time with some other person talking at you is very difficult. It too often keeps the coding at a superficial level that might meet the most obvious requirements, but leaves something lacking. On the other hand, it is often good when you hit a wall to just go to another programmer and talk about it. Sometimes they know something you didn't know, or see something you didn't see, that helps directly, but often simply the act of talking about it solves the problem. So, having another programmer available for discussion is great, but being forced to do everything with them is not.

Matt Van Horn

June 12, 2013

It seems that one of the primary complaints about pairing is that it is taking two people to do work that one person could do. This is only true if "the work" is just slinging some code, but in reality "the work" is:

- writing the code

- reviewing the code

- explaining the code to the rest of the team

- maintaining the code written (by others) previously

Writing the code is just the tip of the iceberg. The communication and learning that accompanies it is more important to the long term health of the code's consumers. When you cowboy code, you can't just measure how quick you wrote the code, but how much time you spent teaching your teammates about it (you did do that, right?) and how much time someone spent reviewing it (they did a thorough review, right - not just a rubber-stamp?). You also have to account for any time needed for a maintainer of that code to get "up-to-speed."

When pairing properly, these all come as part of the deal. Since I pair with different people every day, the whole team becomes familiar with all of the code. Since I write code with another set of eyes & brain helping, I know every single line has been reviewed. Because of these two facts, anyone else on the team can step in and maintain this code with no ramp-up time.

Pairing is a skill, I did it unsuccessfully for a while and did not like it. I blamed it on my personality, but when I finally got on a team that knew how to pair, and how to teach the skill, I realized how much more productive and happy I could be.

My current job does not do a very good job of encouraging pairing, and for me it makes for a very, very frustrating experience. I have to spend hours with git blame, and tracking down people to understand code that is usually poorly designed, because there were a lot of cowboy coders using whatever pattern they just learned regardless of whether it was appropriate. I also wind up being asked to review huge commits full of stuff I've never looked at before - do you think I am really going to be able to do a decent review like that? But the biggest frustration is knowing how fast I could move as a pair, and seeing how slow I (and everyone around me) is without it.

I think it is unrealistic to expect 100% pairing all the time, but I would shoot for as much as possible, anywhere I worked.

JGE

June 12, 2013

No one has mentioned personal hygiene. Bad sense of humor. Or any of the other things that can and do occur if you're forced to sit right next to someone else. Distracting? You bet. Helpful for your productivity? No way.

And beyond that, I happen to be a very fast programmer. I pick up stuff quickly, see solutions quickly, and in my 25 years of experience have met very, very few other programmers who can keep up with me. Pair programming just slows me down and that's all it does.

So, I won't do it. Fortunately, I'm valuable enough to be able to refuse. Yay me. Sorry for those who don't like it but have to do it anyway. I feel your pain.

david

June 12, 2013

in theory i suppose pair programming may have some benefit. however, from a business perspective, it appears that the company is paying twice the labor for the same product. if you match programmers of unequal skill, one will spend the majority of time teaching the other, and i suppose you will get the, "uh huh" effect. i remember asking a recent college graduate at his interview, "do you like working alone, or do you like working on a team?" this was a trick question designed to keep the candidate from telling us what he thought we wanted to hear. software is much like sports teams for track, swimming, and wrestling where each individual's performance is significant and the sum of the individual contributions impact the overall success of the team. i am not a fan of pair programming.

david

June 12, 2013

Charles Kincaid

June 12, 2013

First, great article. Well written. Good job.

Second, bunk! There have been great collaborations. The Wright brothers come to mind. Even older than that? OK. "Let Us make man in Our image." Hey, you brought Steinbeck into this.

Third, different folks work in different ways. I know someone who is a top notch team facilitator. Gets a group of folks to work together and gets amazing results. I know of folks who pretty much can't work side by side with other folks, period. Left alone this person will go off and come back haggard but with brilliant results.

The trick seems to be knowing who is good in what setting and let them work in the way that is best for them. Tragedy results when some pin head tries to force everybody to work in the same way as everybody else.

Me, I am the screwball in this game. On some things I like to be all by myself. I like pair programming especially when I’m trying to get a team member up to speed or when I need to learn some new technology. I like code review, even when it is me in the hot seat.

nickels

June 12, 2013

Well, I 'officially' pair programmed once and it was one of the dumbest things I've ever done.
But unoffically pair-programming, i.e. going into a colleagues office and bouncing ideas off of them as I code has always been invaluable.
Very few coding projects live in total isolation; interfaces to a larger system are almost always key, in which case communication with colleagues is the most important way to avoid going down a bunch of dead end paths and wasting a lot of time. My 50 cents.

20 Year Developer

June 12, 2013

I have done pair programming during very customized installations of large enterprise sytems. Much of this was customizing certain data and such to the needs of our clients. There were often 15+ hour days. This was when pair programming made the most sense -- one person working the keyboard and the other making sure that the first person wasn't using it as a pillow and that what was being typed was what was meant to be typed.

In other environments, I've also found that it makes sense to pair program for a bit, come back together and compare notes and fit ideas together. This way both brains get used but can collaberate for a best-of-both-worlds approach.

I am also a certified ScrumMaster. True agility to me is to allow a team to know itself well enough to make the biggest impact that it can. This means getting rid of impediments and allowing team members to be themselves -- working in quiet, working while talking, or whatever makes sense -- so long as they can respect the team and the individuals in the team. However, the hardest part there is listening to team members (context and subcontext) and asking questions to make certain all members of the team "get it". There are some days that Dev X needs to be left the heck alone. There are other days when Dev X needs to collaberate. That is true also for Dev Y and Z, so they need to understand one another. As long as the work is being done, it then becomes a matter of the team driving the team.

30 Year Developer

June 12, 2013

I have been developing software for a long time and currently manage a team with 6 developers where we always assign 3 projects so that there are always two owners. The two owners of the project pair when necessary and not when it's not. The general rule of thumb is that they don't pair on the tedious stuff, but do on the serious stuff.

We have one guy on the team who thinks and talks very much like you. In fact, I could hear his voice when reading the article and, if you hadn't put your profile on this article, I would have sworn it was written by him.

Unfortunately, while a good programmer and very knowledgable about programming theory, his code is always the most buggy, taking longer to finalize with QA. It is also the code that has the most holes in it ("Oh, I didn't think about that circumstance happening").

We've been pairing in this way for a large number of years. We've even stopped for a few cycles to see what difference it made, and the defect count shot way up.

For me and my team, pairing is a must... we just don't do it 100% of the time.

And, for the record, most of the innovative ideas that we've put in to our product have come from collaborative discussions between multiple develpers, not individual ideas. It almost always starts with someone throwing out a thought, and then others building on it.

Be Like Water

June 12, 2013

In my opinion it's fine that some people don't like pair programming, and it's a mistake to expect everyone to do it.

However, it is not ok for to dismiss PP without finding an alternate way to achieve the goals of PP. The goal of pair programming should always be for a team to facilitate communication, synchronize a shared vision, and minimize the amount of code that only one person is familiar with. I really believe this can be achieved without PP, for example with frequent group code reviews. It just bothers me when I work with people who shun PP and then fail to compensate for it.

Squirrel

June 12, 2013

IMHO, pair programming works in a few situations (some of which have been mentioned already).

1) For a brief period of time, an experienced coder working over the shoulder of an inexperienced one (experienced can either be taken to mean experienced in a specific area, or just general programming knowledge).

2) When two people who are relatively inexperienced in an area have complimentary skill-sets. I've been in groups where both I and my partner were both not that experienced in the target area, yet between the two of us, we were able to churn out a large amount of functionally correct code in a reasonably short time frame.

3) With groups that synergize well. I tend to be able to do clever things with code and grasp some situations quickly, however I also tend to make many sloppy mistakes. Some of the partners that I've worked best with in the past are the ones that are good at reading code, but if they were asked to generate the code that I did they would fail miserably. By pair programming, they are able to catch the slip-ups that I make before even trying to compile, thus enabling us as a group to create better code than either of us would have been able to do separately.

That being said, I still tend to be a loner.

Daf

June 12, 2013

I'm also quite an introvert but pairing is encouraged where I work -- but not forced. I can honestly say that pairing is really good for discovery, for honing your craft (ping-pong pairing for katas, for example), and most especially when one of you is stuck on something (read: been churning for an hour or two, or more) and a fresh set of eyes can really help, especially if those eyes also have a programmer's brain behind them and the ability and willingness to contribute at the keyboard.

Pairing is also a great way to mentor a junior as it gives the senior a feel for the junior's ability level and gives the junior a safety-net and learning dojo. Though some would say that that's not strictly pairing.

Some will take to pairing more easily than others. The benefits of pairing (imo) can vary according to the task at hand, individual personalities and individual proficiencies. I think that the best place is one of learning how to work alone and with someone else.

You can also learn a lot from working with someone else, even if they have a similar skill level to yours. You can pick up style and tips just by observing them. I've paired with programmers with similar experience level to mine (12 years) and more experienced programmers; I like to think that we've both learned from each other in that time -- and been able to take that learning away to apply it when we're solo.

Abner Morales

June 12, 2013

I think those aging programmers are against pair programming. When I think of people saying they have been software engineers for 20 years, I think of companies like IBM, Oracle. Giants where software engineers come in like drones at 9am leave at 5pm. I see value in pair programming, when dealing with hard problems its always better to have a second set of eyes to ensure you don't overlook anything. Maybe the aging developer fears change and that is why startups and leading software companies tend to prefer younger programmers as they are not so set in their ways.

Another 20 year programmer

June 12, 2013

I enjoyed the read, thank you.

I personally prefer to work alone. Though, I have found I welcome pairing at the beginning and end of large tasks. In the middle when I'm grinding through the meat of the task, I want to be left alone.

I also have had to deal with the partner who could not keep up at all during any given normal work day, and the partner who would never go home ( I suppose I was the one who could not keep up in that case ). Um, I even had to deal with one that picked his nose ....

However, I've had good experiences too. The most successful, for me at least, have always been targeted paired programming at certain points in the project.

Dan Sutton

June 12, 2013

Thank you! I've been saying this for years: just as, with a chain, the strength of the whole is equivalent to that of its weakest link, I feel that the same thing applies to programming. If a programmer can't solve the thing alone, he shouldn't be working on it.

As Geoffrey James wisely points out in "The Tao Of Programming":

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''

"It will take one year,'' said the master promptly.

"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''

The master programmer frowned. "In that case, it will take two years.''

"And what if I assign a hundred programmers to it?''

The master programmer shrugged. "Then the design will never be completed,'' he said. "

Stephen

June 12, 2013

Absolutely couldn't have said it better myself. I wish more people would stop following the in trend of the day. I once sat through a meeting showing the benefits of all of these "new" methodologies vs. the waterfall method. I mentioned that all they did was take the waterfall method, take a couple of steps out, condense the timeline down to a week or so and called it something new. I was derided for not being up with the times. I've worked in teams, and have enjoyed it, and I've worked alone and prefer that. I'm so happy I've never had to work in a pair programming environment. Yes, it has the potential to produce better quality code, but doing so by spending twice the money. I've been programming for 20 years. I'm not old and stodgy, but even if I was it would be because I was forced to participate in asinine practices as a developer or face the wrath of the plurality. I have great friends. I am an introvert, but that doesn't mean I don't enjoy being around people. It just means my mouth has a filter.

Andrew MacNeill

June 13, 2013

Anyone who advocates Pair Programming all the time doesn't get it, in my mind.

12 Year Developer gives a good breakdown - the only thing I would add to that is that if your Domain Expert has to do heavy debugging, that's almost a call for a more formal code review or a pair to see HOW they do it. Pair Programming simply offers a way of doing it without creating unneeded meetings.

Andrew's comment about organization stability is valid but ... ( I only hit a quarter of the team with a bus :) )

Having someone that you can bounce ideas off of is invaluable especially to think through an idea.

Having a "pair" also allows you to do informal code reviews and teach/learn with others.

But each programmer still needs to do their job separately. Otherwise you can easily create an "ant/grasshopper" environment where someone feels like the other is getting away without doing any real work.

Talbott Crowell

June 13, 2013

Nice post. I like the idea of pair programming, but have only heard second-hand stories about its successes. There is one flaw in one of your assumptions, though. You state: "There should be no more personal space, and no ownership of work." From everything I've read about XP, you must have personal space (usually a desk away from the pair programming stations). Also, and more importantly, ownership is critical. Instead of each programmer owning a chunk of code that they programmed solo, so it is easy to blame, pair programming and agile requires that each programmer own ALL OF THE CODE. So there is full ownership. If the programmers don't have ownership, not only of the code they wrote, but of their pair peers, then any attempt at pair programming will fail. I don't think it is easy. It is much easier to program by yourself. But some people have found that it is effective.

35 years of programming experience

June 13, 2013

"Nothing was ever created by two men. There are no good collaborations"

Sure like Wilbur and Orville Wright or NASA. Never did anything worthwhile right?

Ben

June 13, 2013

Wow...thanks for the really thoughtful comments. I'm really pumped this post had some impact, and catalyzed some great discussion.

@Roshan - Agreed, "Quiet" is an excellent book. Inspired a lot of this post.

@Gordon Morehourse, @Ilja PreuB - I actually do think the introversion/extroversion dichotomy is relevant, but agreed that it doesn't perfectly explain people's predispositions to like or dislike PP. I'm not trying to make an air-tight argument...just providing a little insight that was helpful for me.

@David Barri - Thanks!

@Mr. Fancy Pants, @David Karapetyan - I know the Steinbeck quote was a little polemic! Of course I don't believe nothing fruitful comes from collaboration. I'm just refute the opposite point, that *everything* must be done collaboratively.

@Matt Korwel - Thanks. Some people mentioned this on reddit, but I actually can't think as clearly when I'm in a dialog with someone else (or when someone's sitting over my shoulder). It's just how I'm built, I guess. I love working in teams, but when it comes to solving a hard problem, my brain needs silence to think things through.

@Simbosan, @Jaideep - Totally agree. This point of view is very foreign/confusing for extroverts, from my experiences.

@Maxxx - I agree that individual devs can create some serious damage, but, for me, code reviews are a less intrusive/costly solution to this. Code reviews take discipline though.

@David, Ulf Andersson - Thanks.

@Daniel - Totally agree...and this is what I'm most interested in: the people dynamic of software development.

Will reply to more later. Thanks for all the great thoughts!

Brian Gray

June 13, 2013

This is easily one of the best arguments (as in points of view) I have heard against pairing.

Let me offer you my (developing) perspective. I am an extrovert, but that doesn't mean I find pairing natural. I actually find it very uncomfortable, probably my biggest weakness is that I think my stupid ideas are better than everyone else's. So I struggle to collaborate and avoid driving in a pairing environment. But I still believe it is ABSOLUTELY the best way to write code.

This was re-enforced by a talk I saw recently by Sarah Mei of Pivotal Labs (where pairing is the MO). You mention a study that found the best predictor of quality of a programmer was how quiet their environment was. Sarah talked about the best predictors of good code being lack of coupling, something else I forget, and finally good communication (I don't have her deck so I can't reference the studies here unfort).

As far as the latter goes, she broke down communication at both the organization level (Conway's Law) and the team level. The more informal communication (hallway chats, happy hours) your team has, the better the communication in the code, the lower the coupling, the "better" the code. And one of the best ways to produce more social programmers is to force them to be social to get their job done.

So people like you and me who may program better on our own, may still produce better code as part of a team while pair programming. Food for thought.

---
The blurb is here, I have asked but not received her deck: http://fluentconf.com/fluent2013/public/schedule/detail/28036

Conway's Law: http://en.wikipedia.org/wiki/Conway's_law

Sam Joseph

June 14, 2013

I take issue with "Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy" --> what about the RSA algorithm?

I think silence is critical at times. However the value of knowledge share that comes from pair programming makes it highly beneficial. If you really prefer silence and alone time to work on a problem, just ask for it. For countless others pair programming turns a somewhat soulless experience into something that helps their own learning, and increases the robustness of the organization they work for.

Arnold Teres

June 14, 2013

"Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy."

Sure Orville and Wilbur Wright, Crick and Watson, Gilbert and Sullivan, George and Ira Gershwin. Just a bunch of do nothing deadbeats who never made any kind of lasting contribution.

What kind of idiot believes this sort of drivel?

Ben Northrop

June 14, 2013

@Sam Joseph, Arnold Teres - Guys, thanks for the comments, but that really wasn't the point of the post. I think you might be taking things a bit too literally. It was just a provocative quote from a famous novelist to underscore the opposite point - that collaboration isn't the only way by which you get good work/ideas - they often come from one person alone.

@Brian Gray - Thanks! Your comment really got me thinking about this. Someone else on the reddit board had a similar thought...and pointed to an excellent New Yorker article that talks about this as well - that the number of serendipitous interactions a person has really has an impact on innovation and creativity. This may be fodder for a follow up post. Anyway, thanks!

ChadF

June 16, 2013

At ~20 years of professional programming (well.. maybe it started at ~2-3 years), my implementation of paired programming was typically when I'd take a break and wonder around to some of my co-workers. If I saw what they were working on and noticed a mistake or them doing something the hard way, I'd tell them there was going to be a problem or suggest that they use [insert-cleaner-alternative-here] instead. The other times it would be sitting behind someone and telling what verbatim code they needed to type to use some API I had [often just] written/committed (hey, why should I have to risk all that extra carpal tunnel ;) ).

Admittedly this was a very weak form of paired programming.

Dan

June 19, 2013

Generally, a programmer's work is more efficient when he is left alone, undisturbed, thinking about what he has to do. But pair programming must not be neglected. It has its advantages, especially when one of the developers is new to the project. Pair programming helps him to better understand the project and allows him to switch faster to a more efficient solo programming.

Eric

July 14, 2013

All of the peer-reviewed research says that pair programming is only beneficial when training. Period. It's embarrassing that our profession ignores this. I suspect that so many people love it because it turns programming into a social activity.

Dave Nicolette

July 23, 2013

Funny you should mention this topic just now. I recently blogged about the same subject. http://davenicolette.wordpress.com/2013/07/06/does-pair-programming-work/

I'm happy to see the numerous comments on your post. It's reassuring to see so many people who take a moment to consider the context before jumping on a "for" or "against" bandwagon.

Mbb

August 07, 2013

Collaborate on detailed design and implement in isolation.

Pawan

August 23, 2013

Well Google was created by two men!

Milos

November 28, 2013

Hi, I disagree. Do you know anybody who goes to wedding by the truck and carry ton of the sand by limousine? The right tool for right purpose. Do you know anybody who has the bad first experience by MLM? By women?

Yes, I know people which I hate co-working even by e-mail with.

But I have several strong experience: my fellow is more analytics oriented and I more technologicaly. So we made the analysis during several discussions and then we implemented it by pair programming. We described the solution, then wrote some pseudocode (structure) and step by step implemented. He took care of business clarity and I algorithm and technology but we revised and corrected each other. It was very effective and enjoyable.

I must notice: He is the leader type, I am very introvert if the Righ is not disrupted.

Some problems require discussion, some hard-alone-work.
Milos

Trabika

December 09, 2013

I don't know if pair programming is beneficial or not. There are as many pair programming situations/environments as there are social interactions between pairs of people. Lets examine a few.

Jake subconsciously thinks women are less intelligent than men. Although he is respectful in all other ways women who pair with him tend to feel a bit "off" during the session.

Mike is a great developer but has never been really vocal. Pairing stresses him out because he feels he should be saying more but the fact of the matter is that most of what he could say he thinks is too trivial to mention. Mike feels like this is not what he enjoys about programming. He enjoys working by himself.

Jane likes pair programming. She is very social. She likes to believe that pair programming is beneficial because she likes to do it.

Bill has odd thought patterns. Bill see's patterns where others do not. Bill usually finishes his work quite quickly and with amazing quality. The problem is that Bill works in patterns that others do not agree with. "No bill lets do this first!" is what he often hears for his pair. This frustrates as he knows he can get the work done faster if he was left to himself.

Jack loves to type and think. Jack loves to try different things. Jack loves VIM every one else seems to love Emacs. Jack wants to be left alone to program with VIM but every time he pairs he is forced to used Emacs to accommodate the majority. Jack feels sad about this.

Robert does not like black people for some reason.

Bob thinks his wife wouldn't like the way Elma looks at him. While it doesn't really bother him too much when he says hi every morning he feels uncomfortable pairing with her. He doesn't wan't to make a big deal out of it because Elma is a nice person and is likely to never cause any issue other than the occasional glance that Bob doesn't like. He still doesn't like pairing with her.

... But of course pairing is the solution to all problems.

Ben

December 16, 2013

Thanks for the thoughtful comments - glad this post has sparked a discussion.

@Eric - Very interesting - if you happen to stumble back upon this post, could you reply with some of the peer reviewed studies? I've found studies, but it was all too obvious that the authors had a pro-pair programming bias, and wanted to confirm their beliefs.

@Trabika - Yup...great point. The social dynamics between different programmers have a much larger impact on the final product with pair programming. It's not clear that all social interactions would lead to happier people...or more to the point, better code (in less time).

Ajinkya

January 06, 2014

Well, Pair programming did work for me. It added a much needed speak element in my working life-style, which makes my mind think in right direction and clear my thoughts.

Mike

March 14, 2014

I have paired in a few environments. When it was not imposed, we did it when it seemed natural, as when exploring a new approach or problem, or researching a deep bug. This worked very well, in my experience, and I enjoyed it.

However, I also worked at a pretty famous all-pairing-all-the-time shop, and it was pure torture for me. It's not an easy place to get into. I badly wanted to be there, and was totally up for trying their way, since it is a very cool company with a million things going for it, but I really couldn't stand the day-in-day-out beat-down that the pairing regimen was to me. I only lasted a couple of months before quitting. I wanted to quit within two weeks. Yes, I quit one of the coolest jobs I've ever had. It was that bad for me.

I think personality does come into it, though it's not necessarily the main driver. I'm a very strong INTJ. Having to interact with another person all day, even if they are a coder, and even if I like them a lot, is very difficult for me. Then, having to code "on stage", while learning a pile of new code and new technologies, didn't work for me either. I prefer to have some time to reflect on things, and do experimentation, by myself. Generally I was too exhausted by the end of the day to do exploration on my own time. I also found I didn't look forward to work the next day.

Then, having my ideas constantly shot down, due to what I perceived as group-think tendencies that seem to grow in such an environment, was demotivating for me. INTJs are idea people that don't care for constraints, and in my experience, a full-time pairing environment placed constraints on me that I just couldn't live with. It felt like my individuality and creativity was not valued. Remember, this is how the job impacted *me personally*. If you fit into that style of work it feels like heaven, I'm sure!

On the other hand, I was at my prior job for 8+ years (I've been in the industry for nearly 30 at this point). This was also an agile shop. At that job I had near total technical freedom and was an informal thought leader and architect, on top of being a coder. We did TDD and SCRUM from the beginning. That was the job where we paired when we felt it would be useful. Why did I leave? We got bought by a much bigger company and suddenly it was a less attractive place to be, for all the usual big-company reasons.

Perhaps it was the contrast between my prior job and the all-pairing job that I couldn't deal with. Whatever, like I said, I could only take it for about 10 weeks and left with no other job offer. That's how much I disliked it.

The funny thing is that I saw TONS of benefits to the company and to the developers at the pairing job, and I still talk the company up when I get a chance:

1) I left with no notice. We agreed upon that. Why was that possible? Because there was total redundancy. Aside from missing my sparkling personality and ping-pong skillz, I doubt that my absence was felt for one second. Excellent for the company, and for me to have that flexibility upon giving notice.

2) The developers I worked with were, for the most part, very skilled at pretty much everything a programmer does in the web dev world. Database stuff, HTML/CSS/Javascript, *nix command-line, IDE use, etc. Everyone I worked with was above average, compared with my many, many prior jobs. This was due to constant knowledge sharing That aspect was awesome. I learned a lot.

3) The pace of work was very fast. The team turned over stories at an amazing rate. Bugs were low, quality was high, the product is great. Whether the story completion rate would have been higher in a non-pairing shop is up for debate. I wonder how the scales would have tipped on the quality side, though.

Sorry for the length. I didn't have time to make it shorter.

Rob Bratton

March 04, 2015

Thanks for the post. I feel the same way. I'm way more productive working on parts of a solution by myself. I do believe in brainstorming on designs and getting feedback from others, just not for doing everything in a group.

Maccurt

February 09, 2016

Man I wish my boss would read this. I am an introvert and what I find the most annoying is that when you try to work alone it is frowned upon

Chanleemoon

February 09, 2016

What the industry needs is a dose of reality.

Managers (and developers who suck up to them) LOVE pair programming, because it's a "thing" and sounds like some kind of best practice to managers, their managers, their managers managers and so on.

The reality in my experience (12 years of minimal pairing, 2 years of full on pairing) is that it doesn't add any benefits, and in many cases as described in the original posters blog, loses the benefits of getting the best out of those who prefer to work alone in a quite space to solve problems.

The classic argument is "you're not doing pair programming right", but the company I have been working for for the last 2 years (and recently quit due to pair programming) are always used as an example of how to do pair programming, and how to reap its benefits. In reality this company is not successful due to pair programming, it's because every time they mess something up they have more than enough money to throw at it until it's fixed.

Rick O'Shea

February 09, 2016

There was never any science behind pairing but the promoters could hide behind novelty simply claiming the studies had not been done. That's no longer true, the studies that do exist are just unscientific claptrap. Clearly, pairing, tripling or quadrupling has its place for a given issue that might arise, but do not extend those extremely unusual circumstances with practical day-to-day development. The current purpose of pairing is consulting firms to rotate untrained staff in and out of consulting gigs, where they charge your company to train them, then charge your company for subsequent work. By pairing they can keep a working rotation going, it's just that you pay double or triple the price.

Demont Washington

September 17, 2016

Totally agree with your points here. I'm currently on a pairing contract, and it's ruining my life.

Coding is very easy for me. Once I've gotten a look at the codebase, I can read a requirement or spec or agile story, and the code comes to life in my head and flows out onto the keyboard. Explaining it to someone else who's less talented, or having them explain their idea to me, is a complete waste of time. Throw in a language barrier - half of my current team is non-native English speakers with varying low degrees of fluency - and you compound the waste. I've written a couple hundred thousand lines of code, most of it thoroughly reviewed and battle-tested. I didn't need anyone to hold my hand to write it. I'm an effective collaborator and love being an accountable member of a team, but pair programming takes that concept to an illogical extreme.

I'm so socially and emotionally drained after a day of pairing that I have no enthusiasm for anything that I used to enjoy. I just want to go home and drink. I should start billing the client for all the single-malt Scotch I'm going through.

Pairing is a desperate attempt to increase quality, and it comes at the cost of productivity and sanity. If you want better code, hire better developers. Give the candidates coding tests, FFS. And when you find a good developer, let her/him work however they want.

Adam

October 17, 2016

Sure, pair programming isn't everyone's idea of fun. But debunking it by using anecdotal 'oh but lots of good things came out of people working alone' is a logical fallacy. Lots of people with bad eyesight drive to work safely every day, but that doesn't mean it's a benefit. For what it's worth (maybe not much), in my opinion, a key benefit of pair programming is avoiding the issues that come from having the low level detail view that programming requires. It's an effort to step out of that to look at the big picture, and takes a lot of self discipline that not all programmers have. Pair programming forces this to happen, lessening the load on self discipline. It forces you to do the right thing. It might be against your nature to want to discuss things, but if doing so forces you to think about the big picture and avoid, say, building the wrong thing, then I think it's worth it.

Brandon H

November 27, 2017

I have mixed feelings about pair programming. In one respect I don't spin my wheel on problems endlessly. But on the other hand I feel I'm being suffocated. I've found that with pair programming, I really don't get a chance to "learn" something new. The way I learn something is through tinkering, and breaking stuff. I feel pair programming really eliminates that. Also there may be something I may personally want to do, and if the other programmer has the driver seat, he/she may not be willing to do it.

I've found that pair programming tends to work better in scramble situations. Such as someone may be hitting a deadline and perhaps another developer may have a few cycles to help out another programmer. This kind of helps bring the task over the finish line. But if I'm doing something that requires a spike, I want to really understand it. And I don't think I really get to understand what I need to do unless I'm allowed to sit down with something and make mistakes. That's harder to do when you have an audience.

bayazet

January 31, 2018

Pair programming - absolutely no! I was forced to try it by my former employer and passionately hated it. Six hours of incessant talking discussing variable names, why not to use inheritance instead of inclusion, why can't we just attach here 4 mb library rather than write 20 lines functionality etc etc etc
By the end of the day I was parched. There is worrysome trend in the industry to use frameworks or heavy library as soon as you need a function or two that does something special. Need to get a character count of the certain symbol - let's use apache commons lang, need to use base32 encoding - let's use some other lib etc. Then we create vicious circle of dependancies whereby one page web app "weights" 80 Mb and includes everything starting from Spring and ending with ActiveMQ libs. I strongly believe less is more. But when programming in pair I constantly get this "let's add a lib" shit. Also I get "this is best practices" and "industry standards" when opponent fellow pair programmer has nothing better to say to justify another lib's addition. My former employer went all the way with Craig Larman's SCRUM, Pair Programming and Test Driven Development. It ended up with firing our executive director, and the guy above him who where in charge of this BS and disbanding all feature teams that were createad in the process. It all went back to the old ways. What I hear now is instead of pair programming they practice "collaborative environment" where all programmers sit at the one long table in the open space having 3 feet of table space per person. They still have daily standups and their meetings are conducted in the same open space at the "team's wall". There could be several meetings going on at the same time. I can't imagine the level of noise. I don't know how people can focus there.

October 24, 2018

Pair programming is a wet dream for corporations that hope to commodify the programmer. When outsourcing and H1b visas arent enough, then at least try to replicate this person and maybe they dont have to pay them as much.

Arion

August 16, 2019

The point I want to make is that even if you're just learning the basics of programming, or if you work in developing, at least you should have enough freedom to chose yourself if you want to work in pairs or alone. Everyone is different and beeing a lone wolf is not wrong.