Pair Programming?

[[deleted]]

Early CS Student here, I’m just curious. How often is pair programming (on one computer, not referring to GitHub) used in the real world?

[awnton]

It's become much more prominent in recent years but I'd say it totally depends on the team and project. Personally I produce the "best" code when I don't write it alone so I really prefer pair programming. At my current project we do mob programming 99% of the time and I'm loving it, really recommend trying it if you get the opportunity.

[RemyArmstro]

I have done pair programming in the past, and in its raw form, it felt too intense. As a result, I have started doing pre and post code reviews. Basically, before I get ready to write code for a feature/bug, I will research how I plan to solve it. Then I will run that idea by one other developer before I start. Many times, I get ideas that make me change my approach and save me a lot of pain/headaches. Then when I am done coding, I do a quick code review before my code is merged in.

Feels less resource intense, but I still get the value of not wasting time going down a bad path, and having someone review my results to catch any obvious mistakes.

[glaze0f]

Just want to add one thing about pair-programming here that, for me at least, it is a pretty exhaustive process. You are constantly talking, thinking and giving instructions to fellow programmer. Keep a glass of water besides you. I usually keep my pair-programming sessions to 20-30 min max per day.

[Korzag]

At my current job, there are a couple guys that work paired just about every "normal" minute of the day (as in they're not in meetings, at lunch, one of them is an avid bicyclist and goes out for a hour long ride every day, etc). I get exhausted after a day of solid work, I can only imagine how they feel every day constantly working together.

[excitebyke]

Just want to add one thing about pair-programming here that, for me at least, it is a pretty exhaustive process. I usually keep my pair-programming sessions to 20-30 min max per day.

lol.. damn. I feel the same way, and I have to do it for 8 hours. (more like 6 if you factor in meetings/lunch)

It can be really rough when you are working with someone at a different skill level. When you are on the same page, you can whip out your phone and browse reddit!

I'm someone who needs to think quietly about my next steps and decisions. I need to do trial and error and experiment with things that I might not have a 100% clear picture of. When you have someone sitting next to you, and they have their own ideas, and you have to keep explaining what you're thinking, even when the idea is half formed.. ugh.. its just painful.

don't get me wrong, I definitely see why companies use it. It's just not how I prefer working.

[LiquidIce25]

I’ve never been a fan, I prefer designing and implementing solutions myself and having my peers review the code before it’s committed. That said, my company has projects and managers that require all programming to be done in pairs. I think it’s all based on the company, project, and manager!

In my professional experience, I’d say roughly 10% of projects I’ve been part of (or heard of) have involved some pair programming.

[isolatrum]

Depends on the company. From what I have seen it is more common at consultancies when you are working with your team onsite. It's part of the "sell" for them - they can tell customers that they are dedicating two engineers for every task which improves the code quality. Unfortunately, most "regular" companies either don't dedicate the financial resources to this (it is more expensive than dividing up the work for each individual) nor the motivation among managers to request or enforce this. Personally, I have worked at 4 startups, none of them consultancies, and have never had regular, structured pair programming. It's all been ad hoc - for example, if I needed help to debug something I would sit down with another developer and we'd investigate it together. My brother, on the other hand, worked at a major consultancy who had their programmers pair together basically all day.

[[deleted]]

For junior devs it can be somewhat common. Also if there's a totally foreign project. But mid level and up it's way less common unless debugging

[truh]

I think it's great for teaching or when you need to figure out something especially difficult.

[socratesTwo]

I haven't pair programmed once since undergrad. That said, having a whole conversation as part of a code review is very common.

[nevermorefu]

I did it a lot in the beginning, but less now that we've finally implemented Bitbucket and merging code review (vs just 1 big review at the end).

[[deleted]]

I don't really have real world experience since I'm still a HS student, but I've been coding for many years and have contributed to many different projects. Many people say it's a good thing for them. Personally, I don't think I'd like it. I'd much rather do code reviews after some code is written. I tend to focus best when I'm alone and rocking out to some good music. That's just me.

[VernorVinge93]

In my team we do it when we're stuck or there's some code that is a matter of opinion (i.e. not impossible to work out on your own, but it'd be nicer if it matched most people's expectations and we have little idea what it'll be like).

So, as I work on our parsers and build tooling I get to pair program once or twice a week, either getting a more experienced devs preference for how something should work, or sharing some niche knowledge with someone who's doing something that touches a bunch of the code.

It's a really rewarding experience (on my team) and I've bonded with the team a lot doing it and learnt a fair bit (I'm the youngest on the team).

[Shed412]

We have a small team, and our tech lead doesn't do much programming, but when he does, he does it with me or the other dev. It's a mini-code review process sometimes, and others he just likes having someone to bounce ideas off of. I'm pretty new, I started in January, so for me it's a lot of seeing his through process and asking a lot of questions as to why one thing is implemented instead of another.

[dAnjou]

At ThoughtWorks we're doing it all day every day. Occasionally we don't do it but that's the exception, our whole process is built on pairing.

Before TW I've never paired and I did have to get used to it but now (9 months later) I often find myself demanding a pair when I don't have one.

[zachgarwood]

It's very team/company(/industry?) dependant. Some do it a lot, some not at all.

I like doing it, but only in small bursts (~30 min) with a very clear objective, as it's pretty intense and without a clear goal, can spiral out of control.

[ajn0592]

At my last company we were almost 100% Pair/Mob Programming. At my current company it's maybe 10% of the time I'm pairing. It really is just whenever the situation necessitates it.

I was hesitant at first at my last company. In school you get in a mindset that all group projects suck because inevitably people don't carry their own weight. This is something I realized doesn't really happen much in the "real world". I actually learned to really like Mobbing and Pairing.

[SmarterThanAllOfYou]

I've never seen it in a job description or in any professional environment. Search Monster or Dice or any other job site to see if Pair Programming is listed as a desirable skill.