DEV Community

Cover image for What's your experience with pair programming?
Madza
Madza

Posted on

What's your experience with pair programming?

Devs who have done lots of pair programming, did you find this way more productive in general? What are some of the main advantages and pitfalls you experienced?

Top comments (23)

Collapse
 
jouo profile image
Jashua • Edited

I don't do lots of pair programming, matter of fact I just did it twice when a co-worker didn't brought his laptop, it felt like having someone backseat developing.

To have the other person feel like being part of the process, I had to ask questions that I could otherwise just search in Google, things like that...

Needless to say, I don't like it, but I'd like to know how other people make it work.

Collapse
 
madza profile image
Madza • Edited

Yup, that's why I asked it too πŸ˜‰
I imagine the scenario you described πŸ˜‰

Collapse
 
israman30 profile image
Israel Manzo

I have done many pair programming in the past, I enjoy to work and learn from other developers on how to approach issues using different directions. The only con of this is that you need to get use to a different types of writing code. According to each person, that was way to be write clean a readable code.., so everyone was right on how they write code and that was some frustrating.
I never took for granted anybody as a competent developer, they were great but I could see how arrogant can "we" be as developers and that helps me to learn that we don't know everything and we still learning, even from beginners.

Collapse
 
eljayadobe profile image
Eljay-Adobe

If you are co-located, and working with someone who is working on the same thing you are, and you both practice reasonable personal hygiene, and you both have compatible ideas of how to go about developing software...

...that can work well. I've done it for two stretches, each stretch about a month long. It was enjoyable.

With the pandemic, and everyone on the team working-from-home, pair programming doesn't seem like a good fit for the situation.

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

I've always hated it. Don't kill productivity and the creative process (which at its core will always be individualistic, no matter how much the "team players" scream otherwise) by trying to combine mentoring with what amounts to bad live code reviews and "collaborative" micromanagement (just delegated to - or self-imposed by - other devs rather than managers themselves).

If it isn't clear, I have nothing but disdain and mockery for the terms in quotes above; at least in the ways they're so commonly misused/abused in toxic tech workplaces (also, "culture" usually equals "cult").

Collapse
 
almenon profile image
Almenon

which at its core will always be individualistic

Can you expand on this?

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

Are you a bee or an ant? There is no such thing as a human hive mind, no "collective brain."

Thread Thread
 
almenon profile image
Almenon

There is no such thing as a human hive mind, no "collective brain."

What about the internet?

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

There is accumulated knowledge, ideally in accessible repositories. That's completely different. Nobody expects every person to re-learn every human discovery from scratch.

The more actuate analogy is this: Unless you're live coding by choice, the internet isn't staring at your screen and following/critiquing your every move. And even if you are, it's going to be far from your most productive attempt at writing code.

Collapse
 
pavelloz profile image
PaweΕ‚ Kowalski • Edited

Did a lot of it, extremely beneficial, especially for Junior-Senior relation (Junior can catch up much faster), when introducing someone new to a project, or solutions that will stay with the company for years - you need more pairs of eyes before commiting to a way of doing it.

Collapse
 
jhwhite profile image
Jody White • Edited

I made the career change to a dev position years ago. In my first job I pair programmed with a senior dev and learned so much. His productivity probably went down, but there were small things I was able to teach him. Or catch small defects that if I hadn't caught at the time would have caused a large time sink to track down.
Overall I'm the kind of person that does well when I have someone to bounce ideas off of, so pair programming starting out was a huge help.

Collapse
 
ksaaskil profile image
Kimmo SÀÀskilahti

I'd love to do it more, it's a great way to share information, learn and become better at getting feedback. Maybe the biggest blocker is the Impostor Syndrome: being worried the other person watching me work will find out I'm not a good coder and they'll judge me for it. A safe working environment might help.

Collapse
 
tngeene profile image
Ted Ngeene

I generally enjoy pair programming because it gives one an insight on how other people approach problems. It's especially beneficial in a senior-junior dev relationship, if the senior developer isn't condescending and the junior is a fast learner. Some junior devs might be intimidated by senior developers and view correction as being reprimanded for their mistakes, this comes when the senior dev is irritable. Generally for me it's a good experience and I've learnt a lot, especially on matters js. You have to find a partner you're comfortable working with.

Collapse
 
xanderyzwich profile image
Corey McCarty

My last team went through a cloud readiness dojo training. It focused on a lot of pair programming. Afterwards we would continue the same. It really helps you to get all the value of a code review in realtime and also allows you to help one another with ways to work faster. there aren't really a lot of opportunities to share your ways of better searching the codebase and find/replace with regex outside of pairing.

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

Never done it, but it sounds truly awful

Collapse
 
walternative profile image
Gregor Beyerle

I like it a lot for tasks, that are a bit more tricky. Banging out API design prototypes with a second pair of eyes is quite productive because you have a potential 'consumer' with you. After a while you can switch, change perspective and repeat the process. Debugging with a partner tends to be quite helpful as well. You are forced to 'externalize' your thoughts (speaking out loud to explain what you are doing) which often helps (me at least) to not trip over logical errors.

For common routine tasks I wouldn't use pair programming. Everything, that is routine doesn't really benefits from a second person. Super creative work (e.g. working on a really weird algorithm or other hacky thing) might also not be the best target as I usually don't have the capacity to vocalize my thoughts in this context. The results from this kind of work could (and maybe even should) be a good reason to get a colleague and evolve on the design.

Collapse
 
derekcrosson profile image
Derek Crosson

I like it. We have a large code base and often there's domain knowledge that only one or two people have (not good but that's how it is) so it's easier to get on a call and chat about it and do some pairing instead of spending a few days trying to figure it out on my own.

Collapse
 
tmack8080 profile image
tmack8080

Watch this. It's hilarious:
youtube.com/watch?v=hc7jHnH5ijE

Collapse
 
madza profile image
Madza

I actually saw this yesterday, hahah πŸ˜ƒπŸ˜ƒ
Was working on fav list of YouTubers and this came up πŸ˜ƒπŸ˜ƒ

Collapse
 
naresh profile image
Naresh Poonia

No experience yet, but I am really excited about it since I believe it will help me learn a lot

Collapse
 
madza profile image
Madza

Thanks for the extensive insight πŸ™β€