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

91–100 of 121 posts

Re: On Pair Programming

#91

Post by jacques_chester »

nikofeyn wrote: post #81
jacques_chester wrote: post #70

Earlier quoted context omitted.

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.

> The easiest time to catch mistakes is early. pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process. there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.

My experience is that it does catch mistakes early. And it's not mutually exclusive of other ways of spotting errors, it's reinforcing.

Re: On Pair Programming

#92

Post by robotron »

jordanlev wrote: post #76
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 break…

Same. I'm introverted but find pairing works well for me. I don't like it if it goes on for more than a day in a row, however.

Re: On Pair Programming

#93

Post by jacques_chester »

nikofeyn wrote: post #80
jacques_chester wrote: post #62

Earlier quoted context omitted.

> 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 h…

> for both pilots and surgeons, no one is doing the same job at the same time.

Do you think pair programmers are literally bashing the keyboard simultaneously?

Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two minds to cooperatively navigate one problem space, which is demonstrably false.

Re: On Pair Programming

#94

Post by robotron »

0x445442 wrote: post #33

So while pair programming what happens with the never ending string of distracting Slack messages and diversions? It just seems completely impractical for the environments I’ve had experienced.

You DnD. If you don't feel like you can do that, then I would suggest you're not in an ideal working environment for fostering productivity.

Re: On Pair Programming

#95

Post by GhostVII »

jtaft wrote: post #90

All around pretty good article. Never thought about using the pomodor technique while pair programming. The part about "informal hierarchies" threw me off, and comes off a bit sexist and racist to me. I read this as "hierarchies that are generally recognized/accepted by the public". I don't believe Fowler intended it to read this way. I think it's okay however to recognize people may have interpersonal issues, for a…

I think that section makes good points about hierarchies between more and less senior people, and between people with a CS degree and people without, but yea I think it is unnecessary to single out white men and imply that they are more likely to try and hog the keyboard or always be in teaching mode.

Re: On Pair Programming

#96

Post by jacques_chester »

Mike12398 wrote: post #78
jacques_chester wrote: post #70

Earlier quoted context omitted.

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.

All these professions require a mix of procedural and declarative skill. Pilots and surgeons aren't professional athletes, they rely on enormous amounts of declarative knowledge.

The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development.

That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".

Re: On Pair Programming

#97

Post by aspaviento »

I had a coworker with whom I did some pair programming and it was painful. He was very talkative, to the point of forcing me to interrupt him every time to come back to what we were doing. Also most of the time he made really hard to follow the code because he took every opportunity to show off his keyboard-shortcut-skills, jumping from file to file, jumping between lines of code, commenting and uncommenting code... all that very fast.

Re: On Pair Programming

#98

Post by mlthoughts2018 »

aspaviento wrote: post #97

I had a coworker with whom I did some pair programming and it was painful. He was very talkative, to the point of forcing me to interrupt him every time to come back to what we were doing. Also most of the time he made really hard to follow the code because he took every opportunity to show off his keyboard-shortcut-skills, jumping from file to file, jumping between lines of code, commenting and uncommenting code...…

This describes every pair programming session I’ve ever had in 15 years and 5 companies. And I’m sure I’m guilty too. Pair programming occasionally helps, but as a frequent practice it causes systemic harm, especially to morale.

Re: On Pair Programming

#99

Post by jacques_chester »

geophile wrote: post #77
oarabbus_ wrote: post #7

Earlier quoted context omitted.

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, waitin…

I found that putting thoughts into words was a skill that became much easier with practice. And then I realised that it forced me to structure my hunches, which would knock some of them out on the spot.

What I did at first was as you describe - chasing down lines of thought quickly, then saying what I thought the answer was. Then I learned to vocalise it through practice. And if I need a moment to think, I can just say "gimme a sec to think" or "can I take a break?" and that's all it takes.

Re: On Pair Programming

#100

Post by flurdy »

cgarvis wrote: post #43
lifeisstillgood wrote: post #31

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review but boy it smashes productivity with a frying pan and keeps hitting it. Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources. It's a tough one to argue fo…

I used pair programming at a startup with a heavy junior engineering team. I loved it cause I could pair with any one of them and that “mentoring session” would be retaught without me having to do it. Our junior engineers progressed really fast in a short amount of time and I didn’t lose my mind having to reteach the same lessons over and over.

I find pairing works well for onboarding new members.

Let them watch for a bit (no more than a few hours) to learn how things work. Then let them drive. Let them explore, make mistakes, but accomplish something and push to prod.

This should make sure all the gaps get filled in quickly. And not 2 weeks later they still don't know how to connect to the database or something basic. Quickly the new members are full team members that can join the normal pairing schedule of the experienced team members.

Post reply on HN