Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Pair Programming

martinfowler.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: On Pair Programming

#71

Post by boojums »

blunte wrote: post #41
mr_custard wrote: post #12

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of menta…

It's not even an issue of "mental resilience". Pair programming, like any other close human interaction, is strongly weighted toward the most aggressive or insensitive (or autistic) personality. And in the tech world, it's very easy to encounter people more weighted toward the autistic end of the spectrum. Pair one of those with one of the HSP people, and you have a really shitty combination. The HSP will expend most…

Would you mind expanding HSP? An online search seems to indicate Highly Sensitive Person which would fit based on context?

Re: On Pair Programming

#72

Post by jordanlev »

xupybd wrote: post #30

I would take less money to get to work like this. The isolation is what I find hardest about being a developer. I work far better in a team with people relying on me. Direct interaction like that makes the days so much more enjoyable. I really hope to one day find an employer willing to adopt this practice. If anyone is hiring I'll apply.

I work for a company that takes agile development practices seriously, and I pair program all day, every day. I absolutely love it -- primarily for the reason you cite (I previously worked mostly solo as a freelancer or remote teammate)... having the direct accountability all the time makes me much more focused and productive. (fwiw, I am definitely an introvert, but a one-on-one situation is much easier for me than a group).

My company (World Wide Technology - Application Services) is hiring -- we have some physical offices across the U.S. and a few in other countries, as well as a growing "virtual office" team (which, while remote, is still in frequent communication and pairs remotely). Email me if you want to talk more or be put in touch with someone about applying (my email address is in my profile).

Re: On Pair Programming

#73

Post by cgrealy »

I find PP useful for complex tasks where two devs can bounce ideas off each other (preferably in a breakout room with a whiteboard).

For the majority of time, it's just not necessary. If the domain is well understood, the code base is familiar and the requirements are well defined, most units of work (stories, PRs, whatever) shouldn't need two people.

Re: On Pair Programming

#74

Post by epicgiga »

The problem is treating this stuff in an "inheritance" rather than "composition" manner. Which is precisely how most managers think, AKA management fads.

Instead of absorbing the concepts behind PP into the mamagement, they'll declare "our team does PP". We're a PP team now. Or Agile. Or Lean. Or whatever. And they'll fit the team to the book, rather than the other way around. It's rife and terrible.

Sure, I "do" PP... maybe a total of an hour a week, to mentor a junior. Which I do without knowing it's "PP", or calling it that, or caring about that as a practice.

When a managerial practice gets a name, it causes more harm than benefit, because every drone manager out there will get all procrustean and damage existing workflows with it.

Re: On Pair Programming

#75

Post by jordanlev »

As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it out).

Some thoughts based on my own personal experience:

* The biggest win for me is I am much more focused and productive throughout the day. Having an actual person to be accountable to on a continual basis keeps me from meandering down unimportant rabbit holes, unnecessary/premature refactoring or re-organizing, and general procrastinating (reddit, HN, etc)

* Development is definitely at a slower pace on a daily basis than what I'm used to working on my own, but over time I think it evens out in terms of quality of code and maintainability.

* Knowledge sharing is huge -- when I was solo, I could never truly take a vacation because I was the only one responsible for my piece of work. Now I'm on a team where we all pair with each other and switch around every day... if someone is out, it's no big deal. Also makes it much easier to onboard new people (the company I work at is a consultancy so projects are always ending and new ones beginning).

* Despite being an introvert, I feel no more "drained" of energy at the end of the day than I ever did at any other job. One-on-one interactions with people I know and build trust with just doesn't affect me the way other social interactions do.

* Pairing is not a panacea. Some of the comments I've seen here are about how horrible it would be to pair and feel judged all the time or one personality overriding the other... I suppose that's possible but it doesn't happen at my job because my company values and encourages trust. My team is comprised of mature people who all value team cohesion and working together towards a goal over having to be right all the time or proving to someone that we're better or whatever.

* I am never "stuck" pairing with just 1 person for a long time... we switch around every day. I probably pair with any given person only once per week (on a team with 6 developers). But each team has autonomy to structure the pair switching however they want.

Those are just some thoughts off the top of my head. Happy to answer any questions anyone may have (and if it sounds interesting to you, my company is always hiring... we have physical offices around the world, as well as a "virtual office" for remote employees).

Re: On Pair Programming

#76

Post by jordanlev »

mr_custard wrote: post #12

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of menta…

I am an introvert (although I don't have social anxiety). I work at a company where we pair program every day. I was very nervous about it at first, but I absolutely love it.

Sure, if your coworkers suck it's going to be horrible. But I've found that most people who go into programming are themselves introverts, so as you get to know your teammates and build trust, you know how to interact with each other, take breaks, not talk over each other, etc.

In fact, I think someone who is more extroverted or someone who is loud/obnoxious, would have a more difficult time pairing since it might be harder for them to listen to the other person and step back a bit.

Re: On Pair Programming

#77

Post by geophile »

oarabbus_ wrote: post #7
geophile wrote: post #5

If forced to choose between pair programming and not programming at all, I think I would choose the latter.

Why?

I haven't tried it, but I know myself, and how I work.

- Interacting with people is exhausting for me. I can't imagine having to be in constant communication with someone sitting right next to me, 7-8 hours a day, every workday.

- Writing software requires deep concentration, and the constant interaction seems like it would destroy the required concentration.

- Having to put everything I'm thinking into words, waiting for a reply, constantly being atuned to social niceties -- how can that be compatible with doing productive work? (Not in general, but for me.) I may stare at the screen for a while, trying to figure something out. A number of ideas go through my head. I run through a bunch of approaches quickly: that's stupid, that can't work, that might work, that's idiotic, ... I go back and reconsider the better ideas in more detail, ... First of all, I am reacting to incompletely formulated thoughts. Forcing those thoughts to be more formulated, to the point that I can describe them, definitely changes the way I would work. Maybe for the better, but definitely different. Second of all, saying "that's idiotic" to a coworker probably isn't a good idea.

In general, pair programming seems like it would take an extremely absorbing and enjoyable actvity, and turn it into torture. For me.

I read a New Yorker (I think) article about how Jeff Dean and Sanjay Ghemawat work together. They seem to do pair programming extremely successfully. Good for them. I have no doubt that it works well for some people. I am quite sure I'm not one of them.

Re: On Pair Programming

#78

Post by Mike12398 »

jacques_chester wrote: post #70
cgrealy wrote: post #68

Earlier quoted context omitted.

Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!).…

Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.

Coding is NOT a real-time procedural performance activity, and thus can not be compared to aviation or surgery. Code reviews, collaboration on architectural decisions, and QA catch mistakes as early as necessary.

Re: On Pair Programming

#79

Post by Mike12398 »

jordanlev wrote: post #75

As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it ou…

You're not an introvert.

Re: On Pair Programming

#80

Post by nikofeyn »

jacques_chester wrote: post #62
nikofeyn wrote: post #57

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in…

> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.

those aren't analogous, like at all. or actually, they are analogous, just not in the sense you mean, as they don't serve as examples of "pair ".

for both pilots and surgeons, no one is doing the same job at the same time. pilots and surgeons, when performing on the same flight or surgery, have different roles, and it's actually extremely important that they stick to and abide by those roles. you know, because it's high-stakes stuff.

however, before and after the flights or surgeries (akin to design or planning in software), or perhaps during sticky situations or emergencies (akin to debugging in software), or during post-flight or surgery reviews (akin to code reviews) they do work together on the same thing. during the sticky situation, emergency, or debugging stage, that thing is the emergency at hand. once it's dealt with, the separate, individual roles are assumed.

so thanks for your examples, as they just serve to further my point.

Post reply on HN