Two years into pair programming: The good and the challenging

[-]

Positive_Method3022@reddit

Usless and waste of time. Do it alone and ask for a peer review

[-]

pyabo@reddit

Hard disagree. Pair programming is one of the greatest productivity tools yet developed. It's the one thing Agile didn't take from Extreme Programming that it should have.

[-]

balefrost@reddit

Agile didn't take from Extreme Programming

I think Extreme Programming is widely considered to be under the agile umbrella. Agile doesn't prescribe any practices. It's a set of values and principles. It's a philosophy.

Are you confusing agile with Scrum?

[-]

Extreme Programming came first. Then evolved into the Agile Manifesto, which was published in 2001. (by one of the same guys that popularized XP) Yes, you can definitely say XP falls under the "agile umbrella", that's totally true. But I was lamenting the fact that XP focused on pair programming, while the Agile Manifesto (and modern developers) don't practice it.

Of course... now we all have an AI buddy to pair program with, so things have kind of come full circle. And look what we're getting out of it: productivity gains.

We could have had similar gain for the last 20 years if pair programming had really caught on.

[-]

balefrost@reddit

The agile manifesto doesn't prescribe any specific practices. It's not that forgot about or were against pair programming. It's that the manifesto is a more general document.

I get it, though. I agree that pair programming can work really well.

[-]

Positive_Method3022@reddit

Yes, that is why 100% of companies use today. Oh... wait...most don't give a fuck

[-]

rcls0053@reddit

Wow. So fast to dismiss a practice that goes back over 20 years and has worked successfully in the hands of some of the best developers in the business. Pair programming is just a practice. A tool among many.

Such a simplistic view to claim it's a waste of time and you should always just do it this way.

[-]

Positive_Method3022@reddit

It is distracting. Put the two brains to solve different parts of the same problem alone. If one gets stuck they can help each other during PRs. Before starting working on those problems discuss the solution to see how they will be integrated

[-]

balefrost@reddit

Put the two brains to solve different parts of the same problem alone.

That's exactly what happens when pair programming is working well. It's not two people doing the same job; it's two people taking on specialized jobs.

The person who's not typing should not be waiting to see the characters appear on the screen. They should be navigating. They should be thinking ahead to what's next. They should also be looking backward - did we miss anything? Do we have any edge cases? Should we refactor after finishing the last task, or maybe prefactor before starting the next task? They should be taking notes.

That lets the driver focus more on the current task. If there's something they want to come back to, they can toss it to the navigator and keep going. Though I think some people discourage it, I've found that it can be useful for the driver to be able to ask the navigator to research something.

I think it's probably like the relationship between a rally car driver and navigator. Like sure, it's possible to drive a car solo around a rally track. But by having two people with different roles and responsibilities, the pair can be even more competitive.

And like that, I don't think you can put to strangers together and ask them to pair program effectively. But man, if you can gel with your partner, it really is pretty neat to see how it works.

[-]

guitarromantic@reddit

Imagine not needing to do a PR review at all because someone else wrote all the code alongside you and already raised all the points they would have later suggested at review time - only you've already implemented them and have hugely sped up the cycle time of the work. There's a reason people do this stuff.

[-]

Positive_Method3022@reddit

That is not how it works. Because when you code together, you are both biased by what you created. That is why Articles written by 2 or more people are still Peer Reviewed.

[-]

doesnt_use_reddit@reddit

The more people look at it, the more likely someone is to find something.

So with two people writing it, there's less likely to be a bug.

So with one person writing it, there's more likelihood of writing a bug.

Not rocket science.

[-]

Positive_Method3022@reddit

I have social anxiety and if I code side by side with someone else, I freeze. I agree that 2 people work better than 1. I just disagree that it has to be done in real time, based on my experience.

[-]

Pictor13@reddit

Funny enough, pair-programming helped me get over impostor syndrome and anxiety.
Developers too often are in their own bubble and close into it as comfort zone, not having the chance to experience how other colleagues/brains work. Pair-programming is HUGE in providing such feedback and fighting siloses.
It showed me I was too oversensitive for my code and put self-worth on it, while the important part was to deliver or improve rather than showing "I'm good". Helped me to be at ease in discussing mistakes, bugs, problems. It made me understood that many things that I was anxious about are "actually OK" and that even more skilled colleagues were still humans, were still making silly mistakes, were still getting stuck reasoning on what "should be simple"™, and it showed me that I am not "tha bad as I tought"™.
Basically if you embrace honesty and let go anxiety (that is a defense mechanism), and embrace discussion instead of (perceived) judgement, pair-programming can do wonders for people with anxiety or impostor syndrome.

Of course the first couple of times you creep; but it puts you there, in front of a colleague, forces you to speak out things and share them. It forces you out of comfort zone, that's why so many introverted Devs hate it........ but the fruit are really juicy.

Peer-reviews only help on technical knowledge/correction, it doesn't do anything to you as a professional, as a human; imho, PRs are very useful, but they increase competence without much increasing professionality.

[-]

Positive_Method3022@reddit

I will give it a try again thinking about what you wrote. It makes sense.

[-]

LosMosquitos@reddit

Your experience is not universal. You might not like it, and don't want to do it, and that's ok. But saying that doesn't work for everyone is just wrong.

[-]

rcls0053@reddit

That is really a one sided view on it. You assume two people of the same experience level and skill. What if you have an inexperienced developer and someone with way better skill? One would complete the work, the other got stuck. One can read a PR, one needs help. What if both are of equal skill, but one simply doesn't have knowledge of the particular app they're developing, while one does?

Pair programming helps in this regard. You should learn to see things from multiple perspectives.

[-]

Positive_Method3022@reddit

What if before solving the problem and divinding the work both raise their concerns and decide what each will be working on. Then they agree that if they reach a wall they can talk to each other? I prefer this way. It could force the wicker side to grow while not stopping a whole other resource to help him upfront. The stronger resource can still be called when needed like I said before.

[-]

doc_steel@reddit

About 7 years ago at my first job I had a scrum master that sat with me for a couple hours every week to explain and help me with my first feature development task that provided really, really good insights over architecture of the software, debated over decisions and straight up offered coding tips that to this day I remain grateful and molded what kind of software engineer I would become.

I think pair programming can be productive, provided both sides can contribute equally!

[-]

chugItTwice@reddit

Couple hours a week... to me that's just good ol mentoring, not shitty pair programming. :)

[-]

Positive_Method3022@reddit

Architecture discussions are useful. In not talking about the discussions you have prior to start coding. I'm talking about coding together. There is no need to do it in Real time. Just try to do solve the issue you both are already aware about alone, then if you get stack go ask for help.

[-]

Melodic_Duck1406@reddit

In God we trust.

Everyone else needs data.

And from what I've read, the data disagrees with you.

[-]

Positive_Method3022@reddit

There is no one truth. It is a matter of preference. Your data, number of likes, says people over here prefer pair programming and nothing else. Pair programming doesn't work for me, and slows me down.

[-]

Melodic_Duck1406@reddit

I'm not on desktop so I can't check.

But pretty sure positive method has edited this comment from 'There is no data', to what it now reads in sn attempt to make themselves look smarter.

I would suggest this person's ego is higher than their intelligence, and probably why they don't like pair programming.

[-]

Positive_Method3022@reddit

"I would suggest this person's ego is higher than their intelligence"

Do you have evidence to sustain this? I'm smart and Im pretty sure I'm no genius. I can do things alone and accept Peer Reviews without a problem. Is this what an egocentric person does? I don't think so. If I was egocentric I wouldn't even like to get Peer Reviews because I would think that everything I wrote has no bugs, right? If you look at all my comments, you will see I said that I like Peer Reviews. This is evidence your comment makes 0 sense.

[-]

Positive_Method3022@reddit

Again you disliked my comment without arguing. Can you explain why you disagree with the above comment?

[-]

Melodic_Duck1406@reddit

You're proving it yourself.

You don't need my help.

I have work to do. No time for pointless arguments.

Perhaps put reddit down for a couple hours.

[-]

Positive_Method3022@reddit

I just want you to tell me how an egocentric person likes Peer Reviews?

[-]

Positive_Method3022@reddit

By the way, even you see on the desktop that I have edited the message, which I'm sure I didn't do it with the intent you described. I could have edited it to fix grammar mistakes, for example. How is that the edited label proves anything? 🤔

On the other hand, there is evidence that I'm not egocentric which is that I defended Peer Reviews in all my other comments. An egocentric person would not think his work needs to be Peer Reviewed.

Like I said, in one of my comments below, I know I'm smart and that I'm not a genius. The reason I don't like pair programming is that it doesn't work for me. I start to have social anxiety and this breaks my performance.

[-]

Positive_Method3022@reddit

When someone implies something about someone else without evidence, this person needs therapy.

The message is the same

[-]

Melodic_Duck1406@reddit

An online study from 2000 showed that 95% of programmers were more confident in their work.

And a recent meta analysis showed it was much more effective when complexity was high, and correctness important.

Studies into it have been going on for at least 25 years.

We have a tonne of data.

That being said, the general consensus is the cost benefit is overstated.

[-]

Ancillas@reddit

Do you have links to the studies?

[-]

DFX1212@reddit

Yeah, two heads are never better than one. Everyone knows that!

[-]

Dals@reddit

If someone is doing remote pair-or mob-programmign and have felt it is easy to loose focus, I've built a tool that helps you keep track of the timer and rotation schedule, give it a try and see if it helps :) https://remobster.io/

[-]

theSantiagoDog@reddit

The only time it’s a good thing is when it’s mutually consented to. Otherwise, it’s a form of micromanagement. I once interviewed at a place that had mandatory pair programming for every item of work. What fresh hell is that.

[-]

chugItTwice@reddit

I've seen mandatory pair programming in job descriptions - I will not even apply to those. Pair programmig sucks.

[-]

pyabo@reddit

Everything about employment is consensual. Otherwise it's not really employment, is it?

I would love to find a place that did full time pair programming.

[-]

MornwindShoma@reddit

Everything about employment is consensual

The only consensual part is that you can quit at any time lol

[-]

pyabo@reddit

That's not entirely true, of course. But the fact that 99% of people are so scared to exercise that option is a huge part of why employers have so much power in our country right now.

Market for developers is bad right now. Worst I've ever seen. But normally we can pick and choose what we do and for whom. We still can, it's just harder right now.

Bottom line: If you're unhappy in your developer job.... it's on you.

[-]

theSantiagoDog@reddit

Not sure what point you’re making. Surely you don’t automatically consent to everything asked of you? You can and should speak up for what you like or don’t like. That’s peon mentality.

Home Depot is who you want. Of course, that was years ago now.

[-]

prl_lover@reddit

I've been in a pair/mob 100% of the time team for the past two years as well. I disliked the idea at first, but it really has grown on me. When you have a good team, it's both enjoyable and productive. I wish I had the opportunity to pair when I was a junior as it's also an incredible form of mentorship.

The real problem I've come across is that lazy team members will sit around all day and do jack shit if they don't have to. If you don't have a team full of dedicated, hard working people then given the opportunity some people will do as little as they have to, which in the world of pair programming means they can get away with doing not a lot. That's a management problem though.

[-]

planodancer@reddit

I had a couple of weeks programming with a peer and that was really cool.

But mostly it just sucks.

Major suck points:

Tiny laptop screen that I can’t see over someone’s shoulder

Excessively junior partner.

Partners who get carsick if I use vim

———-—

I ever had the opportunity to program with an excessively senior partner, but when I see one YouTube I mostly watch in awe and make mental notes.

So that might be fun

[-]

arkie87@reddit

I use neovim btw

[-]

summerteeth@reddit

That laptop screen thing is terrible - if you are going to pair a lot you need a good setup.

I like the two monitors hooked to one machine, mirroring each other and a set of keyboard and mouse for each pair. Sit next to the person and give feedback on how it is going often and take breaks often.

For remote Tuple and Pop are both excellent.

[-]

Backlists@reddit

Partners who get carsick if I use vim

I’m not the greatest vim user in the world, but this proves to me that vim allows you to edit more in tune with your inner thinking process. (Because when that thinking process is removed, it makes people carsick)

[-]

Signal-Woodpecker691@reddit

Pair programming is fine in small bursts, otherwise i find it too draining having to talk continuously and move at somebody else’s speed. If I was expected to do it full time I would get burnt out and quit

[-]

fuddlesworth@reddit

Shit slows me down A LOT. It takes an incredible amount of energy to be able to 1) figure out what I need to do 2) explain to someone else what i'm doing the whole time.

[-]

arkie87@reddit

It might be painful but being able to put it into words makes you understand it a lot better. Whether that trade is worth it is another question.

[-]

thisisjustascreename@reddit

It's great when you vibe well with someone, I've had pairing experiences that were hugely more productive than working independently, but I've also had coworkers that can't fluently context switch between typing code and talking about it which makes pairing a struggle.

[-]

MishkaZ@reddit

I pair program pretty often.

I pair program with a junior and yes, it is draining, but getting them to see my logic and thinking has been paying off. His work is getting noticeably better in the last year.

I pair program with 2 guys who are around my level, but not familiar with rust and a guy who is far senior and more knowledgeable about rust than me. All three of them are great, ends up being us problem solving together or figuring out architecture out together with occasional "this is how you code it".

Idk, I think it really depends on your personality and the person's personality. I like working together with someone, so it works out well for me. But my team lead hates it and prefers to do it more async on slack.

[-]