111–120 of 180 posts
I did work for a few months in a dedicated "everything XP" shop that included religious pair programming. There were half as many computers as there were people, so we were forced, by design, to do pair programming. It broke down really fast . If one of us needed to read some documentation, the other one would just sit and chat while the first was trying to actually learn something. We'd have to take turns reading an…
I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a…
Maybe they will have some helpful suggestions or techniques that will speed up that process...
I think this misses a lot of the benefit of pair programming. The person with more experience on the project can point the other person directly to the places where it's natural to implement functionality, instead of the newbie having to scan through potentially the entire project structure so they can orient themselves. An expert can give a novice a heads-up about things they will be asked to change in code review, so they don't make the mistake in a dozen places and have to fix it a dozen times.
Often pair programming happens because there's a mix of expertise -- there's a change that requires both familiarity with the project and a certain kind of technology expertise, so a junior programmer who knows the project pairs with an expert from another team, and the change gets done faster than either one could do it alone.
Pair programming is also a great way to use excess capacity in a dev team. Martin Thompson points out in one of his talks that a system running at full capacity is slow and fragile, so you want your dev teams to work below capacity most of the time. Pair programming is a great way to improve quality and share knowledge, and when you have excess capacity, it's free!
It depends on the people. Dean and Ghemawat at Google are so used to coding together that Wired wrote about them as if they are one person (hence hyphenated double name in the title): https://www.wired.com/dean-and-ghemawat/ I can see where the author is coming from, but I have also had a few good pair programming sessions. Pair programming where one is more of a mentee instead of a reviewer should be useful to upski…
Sounds like an exception, not the rule. At least, I've never seen two people who coded together all the time. Not in the 20 years I've been a software developer (in both startups and in BigCorpInc).
I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a…
Earlier quoted context omitted.
I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming. That analogy is just yet another way how to shut up people who dont like the process.
> That analogy is just yet another way how to shut up people who dont like the process. In that case explaining why you like anything is a way to shut people up who don't
No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different. But, going into "this makes sense, because two people make sense in rally racing" is neither of those.
Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…
Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch it.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
His argument seems focused on a single output: developer velocity. That's a dangerous metric to optimize for.