Slashdot Mirror
The Programmers Go Coding Two-by-Two — Hurrah?
theodp writes "The Wall Street Journal reports that pair programming is all the rage at tech darlings Facebook and Square. Its advocates speak in glowing terms of the power of pair programming, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web. 'The communication becomes so deep that you don't even use words anymore,' says Facebook programmer Kent Beck. 'You just grunt and point.' Such reverent tones prompted Atlassian to poke a little fun at the practice with Spooning, an instructional video in which a burly engineer sits on a colleague's lap, wraps his arms around his partner's waist and types along with him hand over hand."
Like many workplace practices, it's something worth trying, but not something to be trumpeted as "the way" to do things. Some people get on with pairing, some don't. And it's OK either way. Likewise, there are writers who work in pairs, but many who do great work alone. There are architects who work in groups and alone. So it goes for software developers.
Where it goes sour, however, is when people who find pair programming valuable start tarring anyone who doesn't do it as being error-prone slackers.
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much.
I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
...if anyone is a sf fan here, there's an effect called Focus. It's when a human being is infected with a mind virus that allows for blah blah blah. Anyway, the users inevitably retreat to jargon in pairs or groups because they are in the process of doing things which have never been done before, so they invent tons of new terms on the spot, and occasionally grunt, hoot, and fight each other. It requires handlers, often, to get any use out of the people. This reminded me of that.
If the Facebook team is using pair programming for their mobile apps (on all platforms!), maybe they should try something more traditional because it's not working! They have so many bugs and glitches in the IOS, Android (tablet), and Blackberry apps that they definitely need to try a new approach! Maybe if they TESTED them before releasing, they'd have better results?
This space for rent, inquire within.
All the time i did pair programming it was me doing all the work and the other guy just pointing silly stuff like "missing ;"
I can't think of ANY one that I want to spend that much time around.
My wife can't code, but I would not want to spend that much time with her either.
Now, maybe my girlfriend. But I don't htink we would get much coding done. Besides, she can't code and I don't care.
>and are less likely to waste time surfing the Web
You obviously haven't heard of the phenomenon of "pair surfing".
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Two-by-two is four, duh.
systemd is Roko's Basilisk.
I know it's just a summary and all, but it makes me feel vaguely sad that out of all of the things you can say about him, Kent Beck is tagged as a "Facebook programmer."
so it's eXXXXXTreeme programming again?
couldn't they at least fucking re-use the term.
oh and it's not so bad for some small crunch period.. but for longer periods it really shits on my slashdot browsing habit.
am I now officially old? since they tried selling us this XP shit back before I dropped out of uni.
world was created 5 seconds before this post as it is.
More Programming, Motherfucker.
...for upgrading holodecks and stealing starships.
http://www.imdb.com/title/tt0708668/
Can we attribute the less then stellar applications coming from these two firms to the pair programming paradigm?
I'm sure there are better examples to use besides these two.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Now we only need to convince more females to study comp sci.
If my boss sees this, and pairs me up with L.....before day one is out there will be two fewer programmers. One dead, and me in jail.
So does that mean when you fire someone you will be firing two people?
We used to call that eXtreme Programming: that was the rage a while ago, then went out of fashion in favour of other agile development methods. But that happened a lifetime ago (the early 2000s :p ), and computer fashion have changed more times than I can really keep track.
I guess that the people who were actually programming 10 years ago are now managers, gurus or architects and want to bring back their happy childhood memories (id est, programming with their buddy) back to reality, imposing it on the newer generations.
It's not for everybody - nothing is - but it's definitely worth trying with an honest effort.
Dare to Hope. Prepare to be Disappointed.
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much. I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
Or it has something to do with experience. The elder programmers have seen many programming fads come and go, many claims for the "one true way" to greater efficiency and reducing bugs. Like most fad/pop things, pair programming probably worked in a specific environment, with specific people doing a specific type of task ... but is probably not a universal solution. It is merely hyped as such by the "training" industry, book sellers, etc.
Elders may realize when working in pairs will help and when it will not. I've seen plenty of instances when elders call in a peer for an hour or two for a particular bit of code and then part when returning to the more mundane parts of the code. Or ask a peer to review a bit of code they just wrote.
Why, Internet? Why?
Case 1) One programmer is better than the other. The better programmer does all of the work, regardless of who's typing. The better programmer feels frustrated and slowed down, and the worse programmer feels worthless. Eventually, the better programmer does all of the typing, and the other is simply acting as a very inefficient code review. It's much better to have senior programmers work separately and do code reviews.
Case 2) Two junior/poor programmers. Neither of them is good enough to handle any really tricky stuff. This combo works okay for basic code, but still fails at difficult tasks. To get decent code, it still needs to be reviewed by a senior programmer.
Case 3) Two mid-level programmers who are at roughly the same level. Pair programming works okay in this scenario, but no better than having the programmers work separately and do code reviews.
So with pair programming, does the timeout for posting here get shortened?
People in cars cause accidents....accidents in cars cause people
I love the idea of less web surfing. I have observed that paired programming is great for weak programmers. The sort who can sort of program but aren't really that good. Two of them together usually add up to one good programmer. Two good programmers often add up to a great programmer, but the great programmers often move quickly enough that there is little or no benefit to their pairing. Just sit them really near each other.
Basically it seems that paired programming eliminates weaknesses rather than emphasizing strengths. It would be interesting to sit the genius but gaff prone programmer with the squarely center of the box but obsessively bug free programmer. If they didn't kill each other the pair might be a powerhouse.
In less managed offices often a what would be an otherwise very good programmer sucks because of surfing, phoning, texting, being late, leaving early, lack of focus, or yacking. Pairing them up would shame them out of many of these behaviors.
A wonderful side benefit from paired programming is that the programmers quickly each learn tricks from the other. But this works best if the pairs are periodically rotated. Also pairs are less likely to get stuck and spin their wheels on any given problem. Depending on the complexity and R&D involved this can be a huge win. But if the programming is simple and somewhat rote then there is little benefit. Another rarely sung benefit is that those poor lost programmers are less able to hide the fact that they are, in fact, totally lost.
I don't think that pair programming is a panacea but a solution to some problems. The key is to identify if you have these problems in your work environment.
Kent Beck is well-known as one of the creators of Extreme Programming and TDD. He's an old Smalltalk expert and a design pattern advocate. He helped popularize CRC cards. He's co-authored books with guys like Erich Gamma and Martin Fowler. I had breakfast with him once at a ski resort back when he worked for Object Technology Int'l. =)
Compared to the notable things he's done in the past, working for Facebook is barely a footnote.
We have one big cube with one computer and we put all of the programmers in there. We call it the stable and the programmers are now just referred to as the herd.
Just be disciplined with design and code reviews and be done with it.
This doesn't sound like a plan to improve performance, it sounds like a plan to cut costs on hardware, now you can have one computer for every two devs.
I'm god, but it's a bit of a drag really...
Works until the MBA types wake up ... they then ask why are we paying 2 programmers to do a single programmer's job. Let's save money by firing half of them.
Forget spooning, time to take it to the next level: daisy chains.
Classes started yesterday, and I'm in my senior year at uni, and one of my classes has now been restructured to teach better about pair programming. I really don't understand what the big deal is. If I am programming in a pair, I want both people to have keyboards, and throwing code at the project at the same time.
Suck it and taste...
The other d00d always smokes all my weed and is never holding any of his own.
I think we can all see where this is going.
Programmer centipede.
You know I'm right.
One programmer for doing the work, one lawyer to write the patents.
I've had experience with pair programming. In my mind here are the pro's:
1. It keeps you engaged and prevents your mind from wandering.
2. It is a great way to teach junior level programmers, many of whom suffer from a lack of training and are thrown to the wolves in the beginning of their careers. I would have LOVED pair programming (in small doses) when I was starting out. It's a great way to learn things about a complex system that are not obvious.
3. Different people tend to approach problems differently, and this difference in perspective can make it easier to catch bugs that are not obvious to a single programmer.
The Cons:
1. When abused, it can reduce productivity by distracting coders and not allowing them the space they need to think.
2. It can create a hostile environment where the employee feels that they have no privacy, room to think, and where they are constantly being watched. This is part of why I think management loves it so much, they are outsourcing micro-management to their underlings.
3. It can reduce motivation of individual developers since the buck no longer stops with them, but instead is the group's (or pair's) responsibility. While diffusing some responsibility across the team is not a horrible idea, people tend not to be as motivated. I observed motivation take a big nose dive when the shop moved to XP, since people were no longer as accountable for finishing anything, they just had to come up with a BS explanation for what they did the past day during the scrum, and really, it's a lot easier to BS one day at a time than it is to explain just what the hell you've been doing the past two months.
4. Many poorly designed XP programming environments are inherently disrespectful, and are merely an attempt to turn a programming shop into a factory floor with no privacy. As a skilled programmer, I won't go along with this, and I actually refused to move into this kind of space at my last job, and instead left, along with the majority of seasoned developers.
Overall, I can get some of the benefits of pair programming by walking down the hall, grabbing another team member and saying, "Hey, could you take a look at this?", when I'm having trouble finding a bug. It shouldn't require them to sit there all day.
HERE WE GO AGAIN here we go again ...
anything that is supposed to be The One True Way rapidly finds out how wide the "edge cases" are.
In pair programming this is found in trying to put Orange/Green Irish programmers in a "pair" (or Jew/Muslim) and also is BAD for programmers that are best setup in a "den" and then have Food/Drink shoved into a slot in the door.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Let's face it...this is yet another iteration of the dance we've seen before. Extreme Programming, Agile Programming, and so on. Companies keep hoping that there's a methodology that can be applied to the process of coding and development that will homogenize their workforce, allowing them to look at coders more like cookie-cutter individuals. There are multiple drivers behind this: the difficulty of assessing a programmer's talent during the recruiting process, the desire to use cheaper resources, especially in outsourced business models, and the challenges that result from coders who turn out not to be a good fit with their role. But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.
For your security, this post has been encrypted with ROT-13, twice.
Fixed that for you
1999 called, they want their useless waste of resources techniques back. Nice try Kent trying to jam Extreme Programming on us again.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Facebook is known for its flawless code.
Seven puppies were harmed during the making of this post.
Pair programming to me is just a bunch of snake oil. I've tried it a few times, once voluntarily and the rest of the time under pressure. Why it doesn't work for me is probably a highly subjective thing, but here goes...
1) Switching "driver's seat" requires that you keep getting back into that state of mind that gets things done; highly inefficient and annoying.
2) If you're paired with an inexperienced developer, you spend most of the time hand-holding; correcting a missing ; is one thing, having to explain why doing things in a certain manner is a bad idea(tm) can take up more time than you would've spent just doing things on your own
3) Like many programmers, I dislike having someone look over my shoulder.
Personally, I'm perfectly happy if a spec comes in, code is written, and it's peer-reviewed after the fact. If you have a problem, bounce it around with some co-workers, maybe do some sample code as an impromptu pair, and then each goes back to their own thing. That, to me, is much more efficient.
Then again I'm an old fogey, and eXtreme Programming, Agile, and this pair programming hooha is just a way for a lot of people to make obscene amounts of money giving talks about it. I've not seen a single "agile" project go out the door the way it should have and I've never seen pair programming be more efficient than the "old ways".
YMMV.
There is no sig...
Paired programming is for idiots that can't write good software themselves.
I like to write code that's easily understood. When I work in a pair, I'm forced to explain what I'm about to write, thus the code that's actually written is already verified to be understood more easily.
it may not be fully correct to characterize pair programming as a "master/apprentice" relationship only, or more generally, imply that some sort of imbalance needs to exist (old/young, smart/dumb, experienced/unexperienced) within the relationship in order for it to work.
for example, in university i pair programmed with my buddy on lots of projects. he was better than me at math, and i was much better at the coding. so working this way we were able to finish our tasks with success and ease because we were acutely aware of each others strengths and weaknesses; how to maximize the good and minimize the bad. we were smart enough to realize this.
a pairing only works if the strengths and weaknesses of the people can reinforce eachother. getting two people together with the same skillset will invariably lead to conflict.
The best organizations use a blend of methods; they don't fall into the trap of forcing everyone to work the exact same way at all times.
I have done pair programming and team programming, and in almost every case, half the pair or half the team was not fully productive. IMHO the only time the team or the pair is useful is for design, debug, or code review.
But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.
What some want is for it to be more like "paint by numbers". Sometimes it's OK, but as you say, most of the time it's a poor fit.
Unix is user friendly, it's just selective about who its friends are.
apprenticeships are also needed with less school time and more real work time.
I say a 1-2 year mixed apprenticeship + tech school will work good and give people real skills.
I'm an IT support guy and not a programmer, so it's interesting for me to read this as I'm sure this will become the next "magic bullet" that gets proposed as the "solution to all of our problems" after Agile and hybrid-Agile begins to lose steam. What amazes me is that every few years some new programming methodology gets proposed and it goes something like this...
Outside Observer: But 5 years ago you guys told us that ______________ was the answer to all of our programming needs. And before that it was ____________. And before that it was ____________. Each time your swore that this new methodology would solve all of our problems and each time it was eventually rejected in favor of yet another new approach. So why should I expect this to be any different?
True Believer: Because this time we finally have the right idea!
OO: But that's exactly what you said the last time.
TB: (cough! cough!) Sorry I can't stay and talk more about this. Have an important meeting to go to....
Hey I like pair programming.
I have a pair.
Oh..... that's NOT what it means?
Humor, or feeble attempts aside, I had to do this pair programming.... Once. Had to sit and watch an arrogant FIDIOT cram too much OO up his own hind while flailing with the lack of specificity doing JSF to exact formatted specs. What a waste of my time. The mini-project was canceled when a few of us went to the "boss" and told them the pipe-dream of doing 1.5 years of development into a 6 week JSF re-do effort was going to be a miserable failure... Seeing several of us... the boss got a (rare) clue and canceled the exercise in stupidity.
I prefer using compiler, static analysis tools (we use Coverity for C/C++, but there are many others http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis ), and peer reviews instead of pair programming to find defects earlier.
Back-seat programming seems less efficient for both time and money. The static analysis tools have come a long way and are very good at finding defects programmers miss.
What they really need to do is pair the managers! I've watched management foolishness drive companies out of business.
about pair programming was how it was described that "one would be thinking while the other one typed". Huh?! Shouldn't both programmers be thinking? Maybe their editor wasn't designed very well and the one typing had to concentrate on typing too much. Probably wouldn't happen with a better editor
Nathan's blog
Working on school related project, I have often done this technique. Sometimes as a productivity tool, but most often as a teaching tool. It is also very good for tutoring.
If you want to use it as a productivity tool, you must have a partner that is on your level of understanding. This is fairly hard to find at an academic institution, and probably harder in a work environment.
I couldn't agree more!
I cannot picture myself working on a pair like this. The only way I can see this working is if one developer is writting the unit test code while the other is writting the actual code and both are referring the same set of specs. Oh snap!! Wait ...this is Agile so no SPECS!!!!!!! :D
Facebook programmer Kent Beck.
That seems a little like saying, "Google employee Vint Cerf."
And, as an aside: Damn, Kent. Facebook? I thought you were cool.
Stop-Prism.org: Opt Out of Surveillance
It's finally happened, the software industry is resorting to prison love.
"When information is power, privacy is freedom" - Jah-Wren Ryel
the driver writes code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in.
Driver sounds cool, that's what fighter pilots call themselves too. But observer sounds lame... we should call it wingman. Then we have the driver who writes codes, and the wingman who watches for errors. Plus we get to say cool stuff like,
"You can be my wingman any time!"
Have you ever played a video game in co-op mode? There are a few games where this makes sense: one person steers while the other shoots, or whatever. But most of the time (for me anyway), this is min-numbingly boring. Give me one-on-one competition any time. My kids, on the other hand, love co-op mode! But if we're competing, they aren't much better as a pair, than I am operating everything by myself.
Maybe it is generational. But I'll wager I can keep up with a programming pair any day. But that's an unfair comparison. Really, you're paying two people to work as a pair. So the comparison should be two people like me, up against a pair programmer team. Now we single-threaded programmers are going to run circles around your pairs!
I would think there would be fewer and shorter time outs. But. my impression is that most of the benefit comes the code being inspected as it's being typed, so there are fewer typos to bog down the compiling process.
But this is speculation on my part. Where I work, it is hard to program in pairs. Since we are developping software for controling machines, our cubes are crowded with equirpment. We each have an in-circuit debugger (controlled by a PC application), 3 test boxes (one for operator controls and indicators/displays, another for sensors (both real and simulated) and the third for actuators (both real and simulated)), power supply, oscilloscope and 4 monitors (2 1920x1080 and 2 1400x800) (to display the debug application, communication simulator, logic analyzer. code editor and various documents).
(Years ago, I used to use the Codewright IDE. It had a feature where 2 people could "link" their Codewright sessions and be able to collaboratively edit the same file, each one seeing what the other was typing in real time. I don't know of another code editor with this feature (except maybe Google Documents, which is not appropriate for our needs.).)
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
I see paired programming as just another gimmick to get around the fact that there is no substitute for having experienced programmers and effective code reviews. As a consultant, I've worked on many agile projects, including some involving strict XP paired programming, and didn't see any better quality with that than with anything else. It's all about who you have working on the project, having decent management and a true agile philosophy ... not "agile theater."
I have been experiencing this more & more recently: that recognition that everything comes back around and many people think it is "new." Was it 1999? Was it 1996? Maybe it appeared before that even but I well recall having some higher ups evangelizing about this at one company I was with and then hearing new IT grads waxing poetically about it during interviews in the late 90's. There is nothing new in this, what would be new is if people stick with it long term. I prefer working alone then taking some time to talk with friends who have similar experience to mine, around 20 years, as well as a few more recent entries to the field. We tend to be pragmatists: whatever gets the individual's work done at a quality commensurate with the stage of development is good practice.
Modern systems don't handle multiple users working on the same thing very well. One of the big differences between most computing and military command and control systems is that screens aren't considered private to users. In most military command centers, staff can look at what other staff are doing. This started with the 1960s space program, where all the consoles were really TV screens, and all the screen data went out over an in-house cable TV network as video channels. Any console could look at any channel, and observers in other rooms could look at channels. SAC and NORAD were set up that way, with the same Philco consoles. That continues today. NORAD HQ today looks like a rather bland room with people at computers, but there's a big video switch so anybody can look at any display, and any display can be put on the big screens in front.
This leads to a style of work where one person is controlling a screen, and others are watching what they're doing. Someone will call out to the room that something important is happening on screen N, and other people will punch up that screen, watch, and take actions or give orders. This is rare in the civilian world, but common in the military one.
A few people with backgrounds in DoD programs work that way. Two well known programmers, Bob Boyer and J. Strother Moore, did this thirty years ago. They had a setup where they both worked at home, with a leased voice line and headsets between them. They were both looking at the same screen, remoted from a time sharing system.
Seems like for work that you just need to knock out, you might be even better off offshoring
Offshoring involves a horrible amount of overhead - first a very huge startup cost of figuring out how to work with the remote company, have them give you code, give them access to other services they need to hit, and so on.
Then you have to also spend time describing what you need done, in very minute detail (detail the experienced coder can provide as a project gets going).
Lastly of course there are delays when bugs are found.
The experienced coder can easily "knock out" something simple in 5x less the time, probably also with a great deal less cost even if their salary is high.
Offshoring is only POSSIBLY worth it for very large projects you expect to die in a decade.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"I don't know of another code editor with this feature."
Cloud 9 IDE, a webbased IDE, does:
https://c9.io/site/features/
It's also an open source project:
https://github.com/ajaxorg/cloud9/
There are other I believe.
New things are always on the horizon
The only way I can see this working is if one developer is writting the unit test code while the other is writting the actual code and both are referring the same set of specs. Oh snap!! Wait ...this is Agile so no SPECS!!!!!!! :D
That's the only way I can see it *not* working.
And of course there are specs. The unit tests are the specs!
I just left my 30 year tour programing in US Army Labs. What a bunch of power greedy losers.
Management has to value the cross training that only working in a team can provide. What if your wolf leaves that what do you have nothing. If you had a programing pair, as least the one left behind would know what was going on. If there was no other value, you have to consider having a back up essential. Its like having no back up of your files.
Even if one partner does absolutely nothing but LOOK at the code the other partner is writing, it is the equivalent of a code review by a peer. The effort is not wasted, unless you suck at doing it.
The problem is that it's a code review that takes as long to do as it takes to produce the code.
Code reviews are useful because you spend an hour or two looking at something that someone has spent a week or two crafting. That is where the value comes from. When you only have the output of one pair of hands, but two minds on a problem - sure you are going to catch some minor glitches but nothing that would not have been fixed in less time than was spent by having two programmers working a problem.
Think of it as a "local maximum". You get improved quality of code for a section of something, but the overall body of code is not really that much better and in the meantime you are spending 2x the money (because coders do cost money) on the same problem.
Now if all you have is time and no money, then pair programming might be a great thing. On a personal project for something you own, it might be a great idea. But for IT work the overhead is just too great to do it all time...
One thing I do like is limited pair programming for maintenance, where you work on an issue to solve together. Then the local quality is much more desirable since you don't want to break anything, and two minds are usually quicker to figure out why a problem exists in the system - especially if both of you know different parts. In that case pair programming is excellent, that is the case where I think companies should stick to using it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"Such reverent tones prompted Atlassian to poke a little fun at the practice with Spooning, an instructional video in which a burly engineer sits on a colleague's lap, wraps his arms around his partner's waist and types along with him hand over hand"
Thus combining male chauvinism (all programmers are guys, right?) with the common misconception that the concept of two guys doing something sexual together is so unlikely as to be innately hilarious.
Two dumbass prejudices the industry would be better off without, nicely combined for your convenience. Great job, sport.
Yeah, if you want the seasoned vet to commit seppuku...
Nonsense. One of the tasks implicit for any seasoned vet (especially one that is vested as a senior or principal) is to guide juniors or new members of the team up to speed. Obviously, you don't want your vets to be paired with juniors all the time, as this is not economical (and at some point the junior needs to hit the ground running by himself/herself).
However, in any company (and for any job for that matter) it is a person's task to help others come up to speed if that person has the necessary know-how. It might not be the case for those who just want to fold jeans at the gap, but it is certainly true above a certain professional/salary level.
I must have missed the point where anything Facebook has done was lauded as being technically impressive.
sounds pretty gay man
(1) ... I'm not going to use it
and
(2) ... I'm not going to work for Facebook
Did Gnome 3 also use pair programming?
I get enough of that at home, I don't need it at work.
(Years ago, I used to use the Codewright IDE. It had a feature where 2 people could "link" their Codewright sessions and be able to collaboratively edit the same file, each one seeing what the other was typing in real time. I don't know of another code editor with this feature (except maybe Google Documents, which is not appropriate for our needs.).)
http://xpairtise.sourceforge.net/ - Eclipse plugin with the scent of abandonware.
I'd like a young pretty chick, please. I can do all the coding and she can just make me comfortable while I am doing it.
I don't have much experience on pair programming, but enough to know some pros and cons of it. What mostly bothers me in it is that there's only one computer, so the 1st guy is typing and mousing while the 2nd one has no tools to do anything by himself. Hence, he needs to tell/ask/point/whatever every time. It feels stupid to spend time on talking on missing semicolons, or interrupting the other by pointing and grunting when you could fix the error the moment you spot them, *if you too had some tools*.
They are also both watching the same screen, probably too close in a bad sitting position. So the first thing I'd change is to have two screens, both viewing the same image (clone mode) so that they can sit properly and see well and don't need to breath the same air. Next step would be to add another keyboard and mouse, so that instead of telling the other guy that he missed something there and there, one could simply go and fix it. This would of course require better tools, so that two guys can simultaneously edit the same document and see what the other guy is doing continuously (two different color cursors and mouse pointers?) For example, if you write something and the other guy goes fixing it, some diff view or different color should reveal it immediately. If you don't understand why he changed it, only then you'll ask. Also, when appropriate, both could work on a different part of the file.
Has anyone tried anything like this before? Are there any proper tools for it?
In my field of Engineering we call this quality control. Two sets of eyes must look at every design before it's released for construction because when you are building stuff out of concrete and steel a mistake is a BIG deal that can put engineering firms out of business.
That software engineering is just starting to realize that everyone (no matter how good they are) makes mistakes and everyone should be reviewed just indicates that it's finally maturing into a real profession where errors mean something more than it does currently (just short of nothing).
the driver writes code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in.
Driver sounds cool, that's what fighter pilots call themselves too. But observer sounds lame... we should call it wingman. Then we have the driver who writes codes, and the wingman who watches for errors. Plus we get to say cool stuff like,
"You can be my wingman any time!"
"Bullshit, you can be mine"
And she said it's difficult to suck when she can barely even see it
When I heard my company was going "pair programming", I was about as excited as I'd be if mandatory drug testing for programmers was being implemented. I decided I was going to quit. Then I saw who I'd been paired up with. Holy moly! Can't code worth a damn, but the massages and sponge baths are awesome. I used to code 5-6 hours a day, but now I'm at the office pretty much around the clock. I get extra rewards for meeting the sales department's deadlines, and I can't even remember the last time I was able to finish a rant about how stupid one of their ... I can't even finish this post, she's whispering at me to get back to work now. Later dudes.
i (man) was paired up with a girl. She was fine as a human, but getting work done was kinda pain in the ass.
I could not scroll anywhere and did not understand anything about the codebase and annoyed the hell outta her permanently asking (trivial, but not obviously trivial) questions.
Later when i got my laptop, it was heaven: i was alone, could scroll and look up stuff and together we were much more productive.
And i even had IRC for private + work chat.
I find pairing up to be incredibly efficient. You are more focused, have a pair of eyes looking over an issue together, have more opportunities for learning, knowledge sharing and (something underrated) make mutual decisions on the why's of certain coding methods. This is kinda like having a code review before bad code is written. Or at least if bad code is written, it's not a single person's responsibility (in theory :p) At my current office, I do a lot of pairing sessions. Not necessarily out of habit but whenever we're attempting to solve an issue. I feel that part of the problem when working in team situations is dealing with the decisions people make in coding or attempting to understanding why someone does something a certain way. Even if you have coding standards, structuring code and defining algorithms to handle a solution differ tremendously between people. Adding that second pair of eyes at least help lessen the human failure problems.
Autodesk calls it Worksharing and we've been doing it in Revit for ten years.
paired coders can be dangereous :-)
If you treat your programmers like cookie cutter programmers, the ones who are better than that will go out and find better jobs, and you'll end up with cookie cutter programmers. It's like measuring productivity in terms of lines of code written. You may end up with working software, but you'll end up paying through the nose for a team of 10 crappy programmers to do something in six months that a single good programmer could have accomplished in one.
Funny we are both reading this at the moment :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Well I believe a team leader, who has better idea of end product, can walkover 3-4 developers sit with for a while, go through design, implementation and discuss and resolve the issues with developer can give better results than single developer and utilize resources better than pairing.
- Anonymous COWARD :)
(whats there in the name !!!)
Software engineering is a real profession. But your comparing chess to starcraft.. During the course of an engineering project you don't deal with fundamental changes, you build a bridge, and the river is still there, the roads that it connects to are still important roads, you still have access to the type of steel that you decided to build the bridge with. Not to mention that they might decide that the bridge should be on another continent Then when these changes happen, it's your fault, and you need to fix it.
While I've seen plenty of bad software build by amateurs, I still curse engineers every time a gun jams.