I treat pair programming as another tool in my toolkit.
- It can be great when starting out on a project (where I have someone to talk to about patterns for the code and bounce ideas off of).
- I also like it as a means of quickly introducing someone to
an area of the codebase that they're not familiar with.
- Some days my ADHD is way out of whack. I've found that pairing ping-pong style (I write the test, they make it pass, they write the test, I make it pass) can help me when I'm losing focus by making it more into a game.
- Sometimes I get stuck on something, like a weird bug or a complicated problem. I'll grab a pair, and we'll think through it together. It helps a lot to grease my mental wheels.
I don't think that most people advocate pair programming for everyone at all times, but for some people, it works really well for them. If you work at a 24/7 pairing company like Pivotal Labs, they understand and appreciate that not everyone likes working that way, and they hire accordingly.
I never understood that mentality, frankly. I see so much in common between programmers and craftsmen, and it would be hilarious for e.g. a carpenter to refuse a specialized tool because they ONLY USE PHILLIPS HEAD SCREWDRIVERS. I would think programmers take pride in having a bigger "mental toolbox." (To deflate my own point however I've seen some interesting debates in construction; e.g. plastic or copper piping for plumbing is still apparently a contentious topic?)
I 100% agree that programmers are craftsman, I'd go so far as to say we are a trade/profession and not a "science." Despite this, unlike many other professions programmers show a trait very different to other professionals. We have huge ass egos.
We think we are right all the time and there is no compromise.
I don't find that much different from the other trades I'm somewhat familiar with, except that in those trades they ARE right. As in, there's often one way that's the best way.
I see this attitude mostly in junior programmers (including myself when I was young :)). When you get older, you get to see that everything has its benefits and drawbacks.
Back in 2008 I was running a design agency. We were always looking at ways to work better together and so one day we applied "pair-programming" approach to the UX part of a project.
I must say that it was one of the best experiences I have ever had. We wouldn't always sit right next to each other and only let one person do the work, sometimes we would work on each of our machines but we would maybe spend 70% of the time with only one of us working and the other observing.
From that day I have always tried to do as much sitting together to solve especially the hard parts together, as possible.
A lot of the times we get caught up in these methodologies as if you can only do one or the other.
At least in UX it helps quite a lot when you have some nuts to crack. You don't need to do it 100% of the time, in fact you don't need to do it at all, but it definitely a helpful tool for UX designers if they can get beyond the "someone looking over my shoulder" issue and (I think this is very important) find a good partner to do it with.
>The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I suspect 40% or less of them might benefit from pair programming, which I suspect is where all the buzz about pair programming comes from.
I don't think I've ever been so negative on HN, but fuck this guy! "Look at those schmucks who want a life outside of work. They'll never be as good as I am. They aren't real programmers." I cannot stand this smug, condescending attitude. I think it's poisonous to our community and to our profession. You can be a good programmer and be extroverted. You can be a good programmer and just want to work 9-5. I get the complaint about trying to force it down everyone's throat, but don't act like that makes you better than everyone else.
This condescension towards mediocrity is a natural result of preaching and extolling meritocracy, which Silicon Valley and the tech scene is full of.
Geniuses and high achievers are exulted for the hard work or natural ability which sets them apart from the rest. Their superiority is widely accepted and valued, while the inferiority of the rest who can't or won't achieve as much is implied.
The puritan work ethic that's very common all over the US also contributes to this attitude. If you don't work hard, you are widely considered to be morally deficient.
The interesting thing is virtually everyone is inferior in ability, talent, or effort to someone else (even in their own specialty). The 99% aren't as good (by whatever metric) as the 1%, and even the 1% aren't as good as the 0.1%, etc. But few will openly admit their inferiority (especially at interview time), and many are eager to find faults in others.
In the interest of full disclosure, I'm far from the best at what I do. I long ago realized that in order to be really, really good at what I do, I'd have to sacrifice a lot of my life, and I did want a life outside of work. As a result, my resume, accomplishments, and skills aren't as great as someone who has made those sacrifices. I pay for that in not being as good a candidate for top positions in the field, and in not being able to perform as well.
I'm also sometimes just not that interested in working on whatever widgets my company is churning out, or in their revolutionary transformations of whatever field they're conquering, and I just want to go home to do the things that do manage to grab my interest at the moment.
I confess that sometimes (even often) I am just working for the paycheck. If I had it my own way, I wouldn't work at all, and just pursue my own interests, independent of whether some company wants me to do that or not. But I'm forced by economic necessity to work.
Don't get me wrong, I prefer coding away in a dark cave illuminated only by my wall of monitors as much as the next introvert, and prefer to "pair" with static analysis tools, unit tests, debuggers, etc. - they interrupt me less and don't disrupt my flow.
On the other hand, I've been part of 3+ person "mob" programming clusters a number of times - to tackle tough bugs as a quick rubber ducking session spiraled out of control and became "no you're right, that's really weird... could it be X? Let me look at Y..." (usually fluctuating back and forth between multiple people looking at the same debug session or code, and people splitting off to separately investigate different possibly related things on their own boxes)
Although perhaps this is more pair/mob debugging than pair/mob programming.
> (Frequent interruption is fundamental tenet of pair programming. How anyone can reach peak productivity or enter or stay in the zone for very long under pair programming conditions is beyond me.)
I think it really depends on how you're tackling a problem. On the one extreme, pair programming could be as bad as your manager forcibly interrupting your train of thought for a status update on something completely unrelated.
On the other extreme, both your unconscious stream of "wait, what about..."s and your coworker's voiced stream of "wait, what about..."s on the exact same topic merge rather gracefully into one, redirecting your train of thought more than interrupting it outright.
Where on the spectrum you'll end up depends partly on how well you mesh with the other programmer on a technical level, and partly on your communication skills. There's a lot of programmers out there where their approach is simply different enough that we're usually on different pages, and I'd rather handle them as asynchronous email/chat. It also helps that I've mastered the art of "one sec..." - mostly ignoring audio input until I've managed to finish or save my current thought, at least.
The style of pair programming that is done as a constant process as part of "extreme programming" is pretty silly and simply should not be necessary in the large majority of projects.
Note, temporarily paring up with someone in order to discuss strategy, give a demo, solve a difficult problem, or anything like that is something completely different and is not what is meant by "pair programming" in the "agile" world.
If you have good developers, a well-factored code base, and are using the right tools and processes, it simply should not be necessary to pair up in order achieve a quality result. I could possibly see it helping when dealing with huge "enterprise" spaghetti code bases where every expression produces a side effect and any change will cause a new defect, but those situations are pretty extreme.
I worked at a software company where we did pair programming and test first 100% of the time. We shipped amazing code in timeframes I wouldn't have believed possible for system than could handle scale unheard of at the time (think of the datacenters powering Walmart). All I can say is this guy has some valid points even though I remain a huge advocate of this process. While I loved my time at this place, I had to quit after 3 years because of burn out.
The trick is to have a way for developers to power down somewhat. I'm not sure how you would do that. I never got the chance to figure it out.
>The trick is to have a way for developers to power down somewhat. I'm not sure how you would do that. I never got the chance to figure it out.
When it's time to change pace one of the things I think helps "power down" is to let team members work on things they are interested in or find important. Instead of priorities coming from up high it lets their minds breathe and explore something on their own. The difficulty is in managing to find the time for it.
I had fully assumed the OP was writing some kind of joke or satire, but since folks are taking this seriously...
I really wish some who call themselves introverts would "give it a rest" insofar as using introversion as a childish EXCUSE to avoid any and all interaction with others or as an excuse to selfishly cherry-pick which interactions they will participate in or as an excuse for anti-social, alienating behavior.
Sometimes people need to work together and pair programming has many benefits for mentoring relationships, getting people up-to-speed, and for solving hard common problems that benefit from discussion and exploration. AFAIK, it is NEVER a "permanent" arrangement-- you go back to your own desk eventually, and honestly, if a pair doesn't work out they can always split-up, so suggesting that it is an "all day" exhausting grind is kind of disingenuous.
You're doing effectively the same thing, but in reverse. That article just demonizes introverts.
Both groups exist, they have their differences. One group may have a better average experience than another (I think introverts and night owls, overall, are a bit less socially accepted). But this just devolves into two groups separating and throwing stones over the fence. We should mind our differences and not spread whatever bad experiences we may have encountered due to them onto others who had no part.
> You're doing effectively the same thing, but in reverse. That article just demonizes introverts.
That article—as well as everything else on The Toast—is pure satire, and definitely doesn't pretend to have an actual position in the matter. Based on her writing & twitter feed, Mallory Ortberg is probably not an extrovert.
I don't generally perceive satire as context free, and I've noticed a trend of certain introverts criticizing and trying to distance themselves from "false" introverts (i.e., shy, socially awkward, asocial people), so I'm not sure if I'm convinced our statements are in conflict.
Probably the articles you've read and evangelists you've listened to were biased but it would seem your believe system is jaded by the fact that the one person you think would be suited to pair programming is what you'd call a mediocre programmer. That's fine, but don't you think that is a little closed minded? You're evectively saying that you think the majority of pair programmers are just mediocre and aren't trying hard enough to solve problems on their own.
Forgetting the social side of things and forgetting the typing or the bugs, you must be be able to agree that two heads on one problem is better than one? Having another person to brainstorm some solutions to a problem with is faster and often gets a better solution that either of you would come up with alone?
I find myself to be smarter and more capable of difficult design work when people nearby shut up and let me concentrate. How would two people constantly distracting each other always add up to one smart person?
It sounds like you operate how I usually do; the communication cost outweighs the benefits of collaboration, and it ends up being a tiring and frustrating experience.
I've seen pair teams working correctly, though. Each of them bounces ideas off the other one, and they progress faster than either would've alone. It's like racing two algorithms against each other, each searching a different part of the problem space, and using the first result that's returned. It lets them move on to the next problem quicker.
I don't usually do that very well, but I can't deny that if you've got the right pair of developers, it's a very powerful technique.
Pair Programming is just another tool to add to the set. It works very well with the right environment and the right situation, the same as every other tool/methodology works in its own environment.
The trick is getting the combination right for your team/technology/problem.
So why does the author feel the need to bring things to extremes? Professing that peer programming only work for the minority and supporting it with anecdotal evidence reeks of confirmation bias to me.
> I believe that the strong producers and leaders in the software industry feel the same. The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I suspect 40% or less of them might benefit from pair programming
I don't buy this - weren't Jeff Dean and Sanjay Ghemawat notorious for pairing frequently?
I think he's a bit too "binary" in his estimation of others opinions on the matter. Personally I like pair/group programming about 1/4 of the time. Usually during the beginnings of a big project.
Its great for going "wide" but it sucks for going "deep". Use it when you need it. Don't when you don't.
Now I'll grant you that when you have a manager who likes the buzzword and insists on it dogmatically, you might have a problem on your hands.
Agree entirely! I'm on a DevOps team, and I love pair programming with my boss for an hour or two a week when we're breaking ground on something new during a sprint.
It's tedious when either of us are lost in the weeds, but it's damn helpful when we're fleshing out the rough structure, bouncing ideas off of each other.
It's really just a step above whiteboarding now that I think of it.
I would say though that one benefit of pairing that I've definitely experienced is that it can keep you from chasing bad ideas down deep, pointless rabbit holes. A lot of the time, when I pair (usually informally), the other person sees something quickly that I missed, or questions some assumption I've been making that turns out to have been incorrect or misguided. If I'd had that input, I might have saved a hour or two running into dead ends. But I'm not sure what the best way to balance it would be - I would never want to do the Pivotal-style all-day every-day pairing, but it's hard to know when you could benefit from another set of eyes, especially when you're already deep into something. Maybe a morning-afternoon split on alternating days or something like that?
> The fact that I’m very accomplished and skilled proves that pair programming is not necessary. Pair programming is absolutely not necessary to increase developer productivity or produce the very best product. It would have the opposite effect with me.
Argh, so close to acknowledging the existence of different personality types and seeing each of them as valuable, you know?
This. One thousand times this. The author's subjective judgements of other people aside, from my point of view, mandatory pair programming is a plague on the software industry. If others want to engage in that practice, cool, but I refuse to work at an employer that requires pair programming. I find requiring it to be grossly insensitive.
I could do pair programming occasionally, if a problem is particularly vexing, but my flow depends on getting in the zone and being "one" with my thoughts, and even tuning out and doing something else for 10 minutes or so. Going on a drive, etc. I'm not sure my partner would appreciate that.
My opinion on pair programming is fairly neutral. I used to dread it, both because I'm fairly introverted myself and not very skilled on the social side, and because it is so frequently the subject of scorn, but it turned out to be quite all right. I had some good experiences with it, and some not-so-good experiences.
> It would ruin the quality of my life and my work environment. I, like most left-brained people, am an introvert and can’t comfortably tolerate that much company or social interaction. I find it VERY draining and aggravating.
> None of this applies to me.
> I believe that the strong producers and leaders in the software industry feel the same. The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I suspect 40% or less of them might benefit from pair programming, which I suspect is where all the buzz about pair programming comes from.
This person seems to be writing from a position of a lot of pain. Someone probably forced lots and lots of pair programming on them at some point, they really didn't like it, they're lashing out against it, and they're really afraid of any chance of it being popular. That is understandable. It really sucks when someone forces something on you that's against your nature.
But that kind of thinking, that style of discourse, brings nothing to the table but more fear and pain and hostility between all the different groups of people. Please see this for what it is. It's very appealing, especially if you're more similar to the blog author, to join his ingroup and then look down on all the programmers who disagree with you and who like to go home after work and who you think are not as good as you.
But what a poor place is an arena for figuring things out! If I think pair programming is good, I must be mediocre, and if I go home after work that only further proves the point. I may be driven, then, to spend more time worrying about being a mediocre cog, than about whether pair programming is good or not.
Pair programming most likely suffers from the problem of human cooperation, in that it is rather difficult, and gets progressively more difficult the more advanced the task is, and the more subjective the solutions. It likely doesn't get any easier when those engaging in it also tend to, well, not mesh too well with each other. Such a thing should not be indiscriminately forced on everyone, especially those that do not want it. But that is no evidence that it is fundamentally good or bad.
Granted, I'm likely mediocre, so my opinion means nothing.
My observation agrees: the best hackers are relatively solitary in work. It's introverted work, and introversion suits the work.
Nothing in that should be construed to mean that programming shouldn't be done in consultation with upstream and downstream stakeholders. Just that pair programming and other high-interrupt situations are poor approaches for good work.
Why do you say that it's a poor approach to good work? If you set up standards for how to communicate during the exercise then you will likely find it an enjoyable experience.
My experience is pair programming turns 2 similarly skilled programmers into 1 slightly better programmer. For tracking down really hard bugs it's 100% worth it, especially if the bug crosses code they are both familiar with. But, that's about it.
In the case of large skill gaps it's not really pair programming so much as training etc.
Then don't work in a team, work in contract development. Pair programming is really only good for team environments where everyone has to deal with confusing elements of everyone else's code.
> don’t want to spend all day, a significant portion of my day, or even a small portion of my day sitting next to another programmer writing code
Do it over the internet with a shared tmux/screen session + a voip client.
> I, like most left-brained people, am an introvert and can’t comfortably tolerate that much company or social interaction
There's a difference between being introverted and being unable to handle technical conversations with another individual. If you can't talk to someone over the internet while you take turns in entering text into a screen session you should really look into therapy. I know quite a few people who have made efforts like that and it has helped them by miles work through these frustrations.
Granted I hate most people but I can still have a few technical discussions with them.
> I prefer to think and work quietly and alone
When I pair program the quietly part is definitely one of the major parts. I have issue typing and talking. Pair programming usually works best as follows:
- Get problem
- Talk about the prototypes you want to mock up first
- Write out a bit of the code at a time and listen to see if the other wants to take over
- Keep going until you finish with this prototype then both spitball ideas at each other for how to break it.
- Repeat until done
More then half the time I've pair programmed I've basically talked with my partner for a few minutes about how to solve our problem, I've typed it out, they either took control and pointed out some things (for which I either defended or changed) and then we sat there for a bit attempting to break it. Most of the time is dead quiet.
The only exception is when you ask the other programmer "hey while I type this out can you read me off the param list to X from the docs for Y" and they'll come back and read that to you. I'll count that as an interruption.
> I know there are perceived benefits to pair programming. I know some believe it can help junior programmers advance more quickly. I know some believe it can help reduce bugs. I know some believe it can help create cohesion among team members. Etcetera, etcetera, etcetera… I know there are studies that profess to prove this
I'd love to do a study that proves this to a standard that the author may agree with but I don't think it's possible. I have a few ideas for homework problems in my classes and see who writes more buggy code.
> Frequent interruption is fundamental tenet of pair programming. How anyone can reach peak productivity or enter or stay in the zone for very long under pair programming conditions is beyond me.
Maybe it's just me and my friend I pair with but we have a "no-interruptions" rule. We tell each other when we are done thinking about something. This way we work more in lock-step rather then interrupts. Again, talking to people about this sort of stuff, just like about code, is important.
> If you believe that evangelizing a particular programming methodology is important enough to do it instead of the development itself then you probably are someone that needs pair programming to be productive and effective
I think this statement is the exact opposite of what I think people like me want. This lets you do program faster, and with usually cleaner results then if done by either of the two members. The sum is greater then the parts.
I do agree with the author, they are most likely the majority which is sad.
> I, like most left-brained people, am an introvert and can’t comfortably tolerate that much company or social interaction. I find it VERY draining and aggravating. [emphasis added]
This is the attitude and experience of a misanthropic person, not a left-brained person.
> The fact that I’m very accomplished and skilled proves that pair programming is not necessary. [emphasis in original]
And egotistical. But, who has ever said (that anyone took seriously after more than a moment's thought) that pair programming was necessary?
> note: non-software developers should generally not be managing software developers – it’s like combining fire and water
Peter principal. My best manager was a software guy. My second best was in software when she started, but quickly left it for management. The absolute worst three, engineers in organizations where the only way up was management.
Let skilled managers become managers, and skilled engineers be engineers.
> This is the attitude and experience of a misanthropic person, not a left-brained person.
Disagree with both you and the author here. This is simply being "heavy" on the introvert scale. It really depends on when the aggravation is invoked. If it's invoked before the draining part then yeah probably misanthropic but if it's invoked after the draining part, that's definitely a "natural process" that could occur in any compu..human :)
- It can be great when starting out on a project (where I have someone to talk to about patterns for the code and bounce ideas off of).
- I also like it as a means of quickly introducing someone to an area of the codebase that they're not familiar with.
- Some days my ADHD is way out of whack. I've found that pairing ping-pong style (I write the test, they make it pass, they write the test, I make it pass) can help me when I'm losing focus by making it more into a game.
- Sometimes I get stuck on something, like a weird bug or a complicated problem. I'll grab a pair, and we'll think through it together. It helps a lot to grease my mental wheels.
I don't think that most people advocate pair programming for everyone at all times, but for some people, it works really well for them. If you work at a 24/7 pairing company like Pivotal Labs, they understand and appreciate that not everyone likes working that way, and they hire accordingly.