1
7

[–] hereonachair 1 points 7 points (+8|-1) ago  (edited ago)

Pair programming is great. It's basically a design session in the middle of programming, it's true that you lose some capacity, but the thing about multiple people working on the same code-base is that even if everyone involved is competent you're always bound to have decreases in productivity due to synchronization.

Your experience is clearly that of someone who works on teams with a wild gradient in abilities, but a well recruited team would be far more balanced. The following points are just wrong:

"When you work with 2 then you only get a compromised solution, never the best solution."

"If 2 good developers work at one solution they you only get a 50% chance to have the best solution."

"Good developers that ask for feedback by the team only do it because they are nice to the team. To give the team a chance to also contribute. In reality they don't need the team to nail that project."

All problems in software are the same in the abstract, but different in their specifics and most people have their preferred toolbox of abstract solutions to abstract problems. 2 people don't need to work together to combine their ideas into one good solution, but the biggest benefit is usually from one telling the other why the other's solution isn't optimal and then both try to think of something better.

Apart from collaborating to arrive at a good algorithmic solution, pair programming is also good to get the ball rolling on producer/consumer or API/consumer work, because you can go into it with your own concerns, agree on a contract that addresses all those concerns and then split up later to implement.

For your last point in particular, that's just ridiculous. By that logic you're saying that any piece of software that has ever been written could have been written by a single person... and I guess that's true in a vacuum but in the real world you have deadlines and timetables and to meet those you need more than a single developer and when you have more than a single developer they need synchronization points so that your project doesn't bottle-neck on a single person writing the entire thing while others watch because they didn't reach any kind of agreement before-hand or a total-mess where everyone is working on whatever they think is most important and the same functionality ends up being implemented 12 different times once for every use case, while some other functionality doesn't even exist without pulling in scraps from 12 different places.

0
3

[–] roznak [S] 0 points 3 points (+3|-0) ago 

Your experience is clearly that of someone who works on teams with a wild gradient in abilities, but a well recruited team would be far more balanced.

No that is the myth. You can only create a balanced team by throwing out the good ones and all you get are the averaged developers. The problem with average team is that no one has the horsepower to break through barriers that you will encounter.

It gives you the false illusion that your team is doing great but in reality is vastly under performs. But if you have nothing to compare to so you don't know that your team is not that great.

And yes! Less developers in your team means less meetings, less communication, overhead, less redundant code, more optimized code, better quality of code, less testing, less bugs = More successful projects and higher throughput. But the key is to have a good developer.

1
0

[–] hereonachair 1 points 0 points (+1|-1) ago 

Right, I'm sure other engineering endeavors such as the Manhattan project really just consisted of a lot of crappy engineers and then one good engineer who solved all the problems.

0
4

[–] karaz 0 points 4 points (+4|-0) ago 

I've first seen this idea about a decade ago, and i can't believe that it actually survived to this day. The whole concept is retarded and never worked no matter which way you slice it.

My biggest issue is that programming - as in the actual typing of the code - is fairly simple and straight forward, coming up with solutions is hard. Why in the fuck would you need someone to watch you type. If it's an experienced dev - he knows how to do it, if it's an inexperienced one - he wont learn dick just by watching. He needs to type it himself, fuck it up, fix it, rinse and repeat. In this case a code review has the same effect with a fraction of time spent.

Part of becoming a dev is learning how to deal with issues on your own, how to find information, how to go about learning something you know nothing about etc. You're not going to learn that by watching someone with 15 years experience just churning out the code off the top of his head. The only thing this encourages is leaning on the senior devs for every little problem.

0
0

[–] irl_badass_here 0 points 0 points (+0|-0) ago 

The main issue is that pair programming has to be more than twice as productive as two people working separately to justify itself. When you put two people together to work on the same thing at the same time, you are essentially halving your coding team. Even if pair programmers working together are 50% more productive (which I highly doubt, since programmers working together waste a lot of time arguing and/or explaining themselves), they are still 50% less productive than they would be separately.

If some company wants to pay me a high salary to buddy up with people, I don't give a shit--I'll do whatever as long as I'm being paid. As a business strategy it's obviously dumb though.

0
0

[–] roznak [S] 0 points 0 points (+0|-0) ago 

he wont learn dick just by watching. He needs to type it himself, fuck it up, fix it, rinse and repeat.

You got it! Good code is not by copying what others have done before but create a mindset to solve things.

1
4

[–] goatsandbros 1 points 4 points (+5|-1) ago  (edited ago)

Why do software managers keep coming up with all these retarded gimmicks? Is it to try for the thousandth time to appeal to "underrepresented" programmers? I can imagine few trade-like industries doing this kind of shit.

0
4

[–] Morbo 0 points 4 points (+4|-0) ago 

Managers do this to make their jobs seem more complicated than they really are thereby justifying why they fail to deliver on projects. When a manager throws an untested new project/development methodology into the fray, they are able to throw their subordinates under the bus when the project fails because they can say the team just wasn't able to step up to the plate like all these other companies did in their white papers and case studies. This deflects the calls of incompetence away from the manager and onto the development team. To the manager types it isn't possible to fail under this methodology because it "worked at Google" and surely the team just sucks because they're not as good as Google. The managers and execs agree and the team is then outsourced to pajeets for incompetence and money savings. It's just the way the game is played now but it's not ever going to be a solution.

0
2

[–] totes_magotes 0 points 2 points (+2|-0) ago  (edited ago)

Pair programming is good though when you have a singular issue that collaboration between two experienced programers will solve because you can play off other ideas. This cannot happen in a singular environment.

However, when the experience level of the two programmers is notably different, the only benefit possible is that the lesser programmer can learn and the lesser programmer might bring some way of thinking that the more experienced programmer doesn't have.

As for your commen about a good Dev only asking for feedback is "to be nice," you are 💯% wrong. Save your "know it all" attitude for home life.

0
2

[–] roznak [S] 0 points 2 points (+2|-0) ago 

I don't know it all, it takes only a little bit of more effort to dig into the part I asked. The only reason why I asked them is give them a chance to contribute too.

1
-1

[–] totes_magotes 1 points -1 points (+0|-1) ago 

I ask for code reviews because of brain fry. I ask for code reviews to find out if there are suggestions for more efficient code techniques. I ask for code reviews to see if there's already a company global function library that does what I'm doing. I ask for code reviews to make sure I'm adequately matching some shitty coding styles.

The list goes on. Code reviews are about making the programmer better, not for showing the rest of the team how much you can polish a turd.

0
1

[–] neodevi 0 points 1 points (+1|-0) ago 

Honestly, I can't disagree with any of this. But, I admit that I like other programmers to show me their process and techniques so that I might learn from them. Of course, this isn't really pair programming, it's just the only good thing I ever got out of it while in school where they pushed it.

Maybe I was an unusually receptive newbie, but I did find it helpful way back when. And an advanced programmer could still probably teach me a ton.

0
2

[–] roznak [S] 0 points 2 points (+2|-0) ago 

I also do that. I look how the others do it and what works I integrate into my own work-flow.

0
0

[–] castarco 0 points 0 points (+0|-0) ago 

I don't think pair programming is something to do all the time, but doing that sometimes is a very good practice.

  • It isn't true that very good programmers are able to learn everything by themselves at a good pace. They are human as everyone else, they are fallible, and they are not alone: there are other good programmers that probably know different things... So, yes, eventually, a good programmer will learn everything that needs to do his/her work, but collaborating with other peers will accelerate the learning pace.
  • Even bad programmers can learn something (and "bad" is a relative term).
  • I think that this post is a rant because you think that you're far better than your coworkers... maybe it's even true, but that's not a very good reason to think that good programmers should learn in a lonely way.

0
0

[–] roznak [S] 0 points 0 points (+0|-0) ago 

So, yes, eventually, a good programmer will learn everything that needs to do his/her work, but collaborating with other peers will accelerate the learning pace.

Actually no. It slows them down. And as I have noticed you tend to copy the bad coding from others instead of better coding. The complete group is under the illusion that they work more efficient, but in reality they slowed to the worst developer in the team.

I think that this post is a rant because you think that you're far better than your coworkers... maybe it's even true, but that's not a very good reason to think that good programmers should learn in a lonely way.

It is the hype that pair programming or programming in a team will make the team 1+1>2 better. But in real world situations this is impossible, unless you are at equal footage. But that equal footage can't stay for long, one will speed up the other one will be left behind.

Also by doing pair programming, for you as a developer at this ends up badly as your career progresses. You never are forced into stretching your mind to solve an issue and no one is going to save you. You never learn to find solutions when everything is in fire. You never become better than the competition. You never become the alpha developer. You will end up as a beta developer that can be easily replaced by your company.

Currently I am in an incredible successful team. We work together but we don't do pair programming. We trust each other to complete his job, and they trust me to do my job. We all specialize in one part of the projects, there are no code reviews. However when it is needed, we can jump into the others code and fix the problems. Because we don't do pair programming, we don't waste time in communication overhead.

0
0

[–] castarco 0 points 0 points (+0|-0) ago 

It is the hype that pair programming or programming in a team will make the team 1+1>2 better

Among the pair programming proponents, I haven't read or listen nowhere that pair programming is a practice to speed up the development. Its purpose is completely different: its purpose is to obtain high quality pieces of code.

We all specialize in one part of the projects, there are no code reviews

Shame on your team. Code reviews are essential, even for highly qualified teams. I know, I know, you don't believe that doing pair programming could help to obtain better software. But probably it has some relation with the fact of not doing code reviews...

Code review is something that has to be mastered too. Not every code review is valuable by itself, because the first times, or even the first months, people tend to focus their attention to minor issues, while disregarding very important aspects of the software. As the team evolves, and skilled and experienced developers enter into the team, the code reviews dynamics change very drastically, and then, when the critical view becomes predominant, code review features its maximum value, but also pair programming for the same reason.

You never become the alpha developer. You will end up as a beta developer that can be easily replaced by your company.

On the contrary, I'm sort of an "alpha developer" in my current company, and as I previously said, pair programming isn't something I do every day, but it's a valuable practice in many situations. In addition to that: as many people has told in this discussion, pair programming has to be done with relatively balanced pairs, not with people that have a very big gap between their skill levels.

0
0

[–] carlosomar2 0 points 0 points (+0|-0) ago 

I had an experience of doing pair programming when neither of us knew the system well because we were both new to the team. The session was for a few hours, then rest on your own. The resting time gave us independence to explore the system by ourselves and then come back to talk about design and new ideas. It was a great experience because I always had somebody to bounce my ideas with.

0
0

[–] vantile95 0 points 0 points (+0|-0) ago  (edited ago)

The article is very detailed and meaningful. I will use it kiểm tra số điện thoại

load more comments ▼ (3 remaining)