5 ms·
If forced to choose between pair programming and not programming at all, I think I would choose the latter.
by geophile 7y ago
If forced to choose between pair programming and not programming at all, I think I would choose the latter.
- oarabbus_ 7y agoWhy?
- artsyca 7y agoI'd venture 99% of pair coding is done by people who don't know why they're even doing it and set themselves up for failure at the outset ultimately crying sour grapes
- downerending 7y agoNot OP, but for me, it's like having someone stand over my head with a pot, banging it with a spoon incessantly. It utterly destroys my ability to concentrate. Had a chance to closely observe a session once. Looked through the code later--total garbage. Apparently it works for some, but you couldn't pay me to do it. (Also, seems unfair to programmers that can't hear well or need other accommodations.)
- oarabbus_ 7y agoWere you coding with someone either much more, or much less experienced than you? Without knowing the case, this could affect how successful the pair coding is.
- downerending 7y agoTwo people somewhat less experienced. I don't believe that was the issue.
- byeager 7y agoOut of curiosity do you think they benefited from the experience?
- downerending 7y agoHard to say. The code that was produced was worse than useless, IMO. I think they were programmers that had both peaked (and stopped learning) when they were young. I'd guess they're in management now.
- cgarvis 7y agoPairing programming is like any skill. If you never do it, you will be terrible at it. I also believe that pair programming requires a level of psychological safety that not all orgs possess.
- downerending 7y agoPossibly, but the time and energy it would take to do that would be far better spent brushing up on new and not-recently-used technologies. Ability to produce quality code is far down the list of my weaknesses, and life is short.
- cgarvis 7y agoGoal of pair programming isn’t better quality code, that is a side effect, but better quality solutions. It’s one of those 1+1=3 types of things. It is also a great training tool. Can’t tell you how many times I’ve had junior engineers ask me about something that I thought was common knowledge or wouldn’t have thought to mention cause I thought it was trivial. It’s a tool in your toolbox. Don’t use it on every problem.
- downerending 7y agoI'm happy to discuss things at the water cooler or in front of a whiteboard, and this seems to be an efficient way to discuss design or help junior people. But sitting next to someone at length is rarely helpful, to me.
- agumonkey 7y agoit can surely be, but do you happen to have times where you sluggish and facing a problem you're very far from knowing how to solve ? in which case it helps making progress. I'm mostly speculating based on my small experience
- NoodleIncident 7y agoIt's pretty much the opposite of what attracted a lot of current programmers to the field in the first place. Even if it were objectively better (which I doubt), I don't think it would be popular.
- bitwize 7y agoTry using an old version of Visual Basic. Note how when you type something with a syntax error and then cursor off the line, the IDE will flag up the error with a modal dialog box you have to dismiss before you can continue. That's pair programming, except the modal dialog box is a smelly human looking over your shoulder.
- bussierem 7y agoThis is the most accurate description I've ever found of my experience with pair programming. Thank you!
- wvenable 7y agoNo pair would ever let me go off into the experimental wilds that are ill advised but is also where greatness can be found. Some of my best and most important projects have started out as terrible diversions that after a while even I begin to wonder if I shouldn't be doing it.
- Mike12398 7y agoFor many of us, perhaps most of us, being forced into Pair Programming completely destroys the enjoyment and fun of programming. For people like me it's the difference between loving my job, or hating every second of it and not wanting to get up for work in the morning. Frequent peer review and collaboration on important architectural decisions is sufficient. Sitting down and actually writing code together is unnecessary torture. Imagine some legendary coder like Linus Torvalds or John Carmack writing the Linux Kernel or the Quake engine side by side with another dude at their keyboard all day every day. It's a fucking absurd and infantile concept.
- geophile 7y agoI haven't tried it, but I know myself, and how I work. - Interacting with people is exhausting for me. I can't imagine having to be in constant communication with someone sitting right next to me, 7-8 hours a day, every workday. - Writing software requires deep concentration, and the constant interaction seems like it would destroy the required concentration. - Having to put everything I'm thinking into words, waiting for a reply, constantly being atuned to social niceties -- how can that be compatible with doing productive work? (Not in general, but for me.) I may stare at the screen for a while, trying to figure something out. A number of ideas go through my head. I run through a bunch of approaches quickly: that's stupid, that can't work, that might work, that's idiotic, ... I go back and reconsider the better ideas in more detail, ... First of all, I am reacting to incompletely formulated thoughts. Forcing those thoughts to be more formulated, to the point that I can describe them, definitely changes the way I would work. Maybe for the better, but definitely different. Second of all, saying "that's idiotic" to a coworker probably isn't a good idea. In general, pair programming seems like it would take an extremely absorbing and enjoyable actvity, and turn it into torture. For me. I read a New Yorker (I think) article about how Jeff Dean and Sanjay Ghemawat work together. They seem to do pair programming extremely successfully. Good for them. I have no doubt that it works well for some people. I am quite sure I'm not one of them.
- jacques_chester 7y agoI found that putting thoughts into words was a skill that became much easier with practice. And then I realised that it forced me to structure my hunches, which would knock some of them out on the spot. What I did at first was as you describe - chasing down lines of thought quickly, then saying what I thought the answer was. Then I learned to vocalise it through practice. And if I need a moment to think, I can just say "gimme a sec to think" or "can I take a break?" and that's all it takes.
- artsyca 7y agoI'd choose not programming over a team of solo virtuosos and 10x feature factory cogs myself
- at_a_remove 7y agoI was forced into it for a few months when it was hot and Agile was still XP (Extreeeeeeme Programming). I found it agonizing. I was unable to do anything deeper than code the simplest functions. Everything I "accomplished" felt shallow and I could not come up with something better until I was unpaired. Sure, I could bash out comments and boilerplate and dumb little helper functions, but the part of my brain that seems to spit out the mysterious solutions that are the point of the whole exercise was dead silent.
- Mike12398 7y agoPairing destroys deep focus. It's an impediment for hardcore coders. Maybe it appeals to extroverts with short attention spans who prefer to socialize rather than do their jobs.