Clarification Needed on the Concept and Contexts of Pair Programming
Hi Taro Community,
I’ve often come across the term ‘Pair Programming’ within discussions here and in the broader tech community. However, I realize that I may not fully grasp the various contexts in which this practice is applied. Could anyone shed light on what Pair Programming entails and how it might differ across different settings or scenarios?
Specifically, I’m curious about:
- The essential elements that define Pair Programming
- Variations in approach when it comes to Pair Programming in a remote vs. in-person environment
- The benefits and potential drawbacks of this method from your personal experiences
- Situations or types of tasks where Pair Programming is particularly effective or, conversely, not recommended.
Understanding this could greatly influence how I collaborate with my team and contribute to our projects. Any insights or personal anecdotes on this subject would be greatly appreciated.
Thank you for your help.
Discussion
(3 comments)- 0
6 months agoTech Lead @ Robinhood, Meta, Course HeroWhat pair programming entails is covered in the name: It's when a pair of engineers sit down together to code through something together. If you're in-person, you should literally sit side-by-side at the same desk. If you're remote, you need to join a video call together and someone has to screen share.
In pair programming, there is usually a driver and follower. The driver is the more senior/knowledgeable person about the codebase and the follower is doing their best to learn from the driver while following their instructions.
The biggest downside of pair programming is cost. Taking up 2 engineers' time is way worse than taking up 1 engineer's time as software engineers are paid a lot. This is generally why pair programming shouldn't be used that frequently, and most companies live by that mentality. If you constantly need to pair program as the follower in order to get anything done, this is a likely sign that you aren't independent and you are at huge risk of a PIP.
That being said, pair programming is great when you're new to a codebase for whatever reason (just joined the company, switched teams internally, decided to pivot stacks). In this case, you should pursue it aggressively with the goal of weaning yourself off of it quickly.
Here's another great thread about pair programming: "How often do you pair program and what do you make of them?"
- 06 months agoMid-Level Software Engineer [OP]Microsoft
@Rahul .. any thoughts on this ?
- 06 months agoTech Lead/Manager at Meta, Pinterest, Kosei
Pair programming works best when each engineer can learn from the other. If there's a very clear skill/knowledge gap such that one person is not even able to follow along, pair programming is simply a waste of time.
Storytime: In my first internship, I was very new to the programming language we used (Ruby), and in fact, I was very new to programming. I paired with a full-time employee who was "driving" and I was trying to keep up. But I simply couldn't. I couldn't understand what he was doing, and eventually, I stopped asking questions. It was a waste of time for both of us and didn't build a good relationship between us 😨
The best pair programming sessions are where the follower can ask good questions ("Have we thought about refactoring this method?" or "I'm curious what keyboard shortcut you just used").
The other dimension is that a lot of pair programming is contextual. Some companies embrace it, but in other companies (maybe Microsoft is one of them?), it doesn't really happen. I think it's worth asking to pair program, especially when you're new, but keep in mind what the cultural norms are.
