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

31–40 of 121 posts

Re: On Pair Programming

#31

Post by lifeisstillgood »

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 for.

Edit: Things I want to try - Tennis Programming - sit next to each other, one writes the tests, one writes the code, swap round often, run on shared disk space or something. Spending ages watching someone else code is just being a human syntax checker. Swapping and diving in to code after ten minutes might be more interesting.

It's like writing a joke or a scene in a movie then handing the paper to your writing partner. You need fast feedback.

Re: On Pair Programming

#32

Post by hinkley »

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…

For such a person, short periods of pair programming might be sustainable, but beyond that you'd expect two reactions: either the become combative as they reach the end of their rope, or they shut down, at which point they are just the chauffeur and the other party is calling all the shots. One of those is immediately and obviously detrimental to teamwork, the other is just as bad because it's insidious.

Neither is improving productivity or buy-in. I think pair programming works best when, upon discovering any two independent tasks, you have the pair split up for a while, do the task, and bring back the code to share. This is not about going faster, it's about getting a break from one socially and mentally intense activity. It's similar to the reason I vehemently insist on a 'bathroom break' for any meeting over 90 minutes. Get some air. You'll get to the outcome faster, and often a better outcome.

I know a few people who'd go so far as to suggest that these practices (being volun-told into all-day pair programming, or god help you, mob programming) are discriminatory. I'm not sure I'd go that far but if one wanted to argue that I'm not gonna stop them.

Re: On Pair Programming

#33

Post by 0x445442 »

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.

Re: On Pair Programming

#34

Post by xvector »

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 consider myself rather socially anxious and introverted. I pair-programmed at a startup for the whole day, every day, for over two months, for an internship.

At first it was terribly exhausting and not very fun but over time it just becomes a part of your day. I think most people can get used to the increased level of social interaction as just something they do as part of work.

What's essential is taking breaks. We had a pomodoro timer running on every team. Some teams took a 15 minute break every hour. Some took breaks more frequently, some took breaks less frequently. I noticed that more introverted teams took breaks more often.

Re: On Pair Programming

#35

Post by Consultant32452 »

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 work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.

Re: On Pair Programming

#36

Post by yepthatsreality »

_y5hn wrote: post #21

Nothing wrong with "pair programming". It's only natural when people are friendly, engaged and cooperating, in that order. It's the environment that actively sabotage such way of working, or attempts to mandate it as a ritualistic practice, that is unnatural. A natural extension of two people in front of a whiteboard, nothing more.

Agreed. The stigma around it seems to be that either side can treat pair-programming as a pop quiz when really it’s just another set of eyes and a discussion.

Re: On Pair Programming

#37

Post by lifeisstillgood »

Consultant32452 wrote: post #35
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 work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in th…

I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor.

I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...

Re: On Pair Programming

#38

Post by Ididntdothis »

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…

The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.

Re: On Pair Programming

#39

Post by cgarvis »

downerending wrote: post #27
cgarvis wrote: post #20

Earlier quoted context omitted.

Pairing programming is like any skill. If you never do it, you will be terrible at it. I also believe that pair programming requires a level of psychological safety that not all orgs possess.

Possibly, but the time and energy it would take to do that would be far better spent brushing up on new and not-recently-used technologies. Ability to produce quality code is far down the list of my weaknesses, and life is short.

Goal of pair programming isn’t better quality code, that is a side effect, but better quality solutions. It’s one of those 1+1=3 types of things.

It is also a great training tool. Can’t tell you how many times I’ve had junior engineers ask me about something that I thought was common knowledge or wouldn’t have thought to mention cause I thought it was trivial.

It’s a tool in your toolbox. Don’t use it on every problem.

Re: On Pair Programming

#40

Post by th_1578953940 »

mr_custard wrote: post #29
_57jb wrote: post #18

Earlier quoted context omitted.

It sounds like you and I are very similar. I was part of a company that went down the road of XP...it was very difficult for the first 6 months but it changed my life. I am much different now than when I started (I am actually in a role where communication is a big part of my role)...I forced myself to stick it out. Not going to lie there were a lot of tough moments on long train-rides home but I not only learned a t…

I appreciate your positive encouragement and that you took the time to write. I'm glad that you jumped in at the deep end and that it worked out so well for you :-) I'm still not convinced that it would be good for my wellbeing and happiness, given that I've experienced PP for a couple of weeks on and off (not anywhere near 6 months like you!). I do like to collaborate with co-workers to solve problems, for sure, and…

Mine does too! I would generally describe myself as an ambivert (right in the middle of intro/extrovert) and I would say 6 to 8 hours a day on pair programming is too much.

I've only been at one company that has so I'm not sure how other shops do pp. What I find really helps me is actually taking turns at the keyboard with a timer every 10, 15, or 25 (pomodoro work interval) minutes. Take frequent breaks. Also, splitting it into two 2-hr sessions, one in the morning and one in afternoon. Increasing the time between your turns by turning the pair into a mob also helps.

edit: And maybe only 2-3 times a week.

Post reply on HN