4 ms·
I had the rare privilege of pair-programming 40 hours a week for several years early in my career. This follows the extreme programming ethos of "everything in
by gavmor 3y ago
I had the rare privilege of pair-programming 40 hours a week for several years early in my career. This follows the extreme programming ethos of "everything in the limit," where pairing is "code review in the limit" and "mentorship in the limit," to say nothing of the oral tradition it imparts[0].
Even pair-programming with my fellow juniors was both more productive and more educational than a rubber duck[1].
I had the opportunity to sit down to dinner with some very junior devs at a family gathering, recently, and to hear of their isolation due to remote-work broke my heart. They simply have no idea what they're missing.
0. https://www.youtube.com/watch?v=4PaWFYm0kEw https://www.youtube.com/watch?v=4PaWFYm0kEw
1. https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
- mattnewton 3y agoAs a counterpoint, I have a hard time coding with other people, it’s like part of my brain spends the whole interaction thinking about what they could be thinking and I usually can’t shut this off. It’s especially aggravated if the person isn’t very familiar to me. For leetcode style interviews that means I basically memorized hundreds of kinds of problems and pattern match to them because thinking deeply while supervised just doesn’t reliably happen for me. I know mentorship is important and spend quite a bit of time on it everywhere I work, including with pairing. But the costs to many senior people’s productivity are very real and can’t be stated lightly. Remote work has been a godsend, previously I would do my best work behind a closed office door, in the back of a company bus, or after hours at home and it’s like having unlimited access to that zone.
- breischl 3y agoI think it can work great for some people. I did it for a few weeks at one point, and found it thoroughly unproductive. 90% of my time was spent waiting for somebody else to type something, or trying to verbally communicate something that would be better done in writing/code. Even now I find it incredibly off-putting to have somebody looking over my shoulder when I'm trying to work, to the point that I basically just can't. People have asked to watch me do something, and my response is that you can either watch me, or I can do it, but not both. It's like Heisenberg Uncertainty for work output.
- gavmor 3y ago> waiting for somebody else to type > trying to verbally communicate something that would be better done in writing/code > somebody looking over my shoulder At the risk of sounding flippant, none of these activities comprise pair programming. What's better written should be, and the simplest way might be "can I just show you?" or, from a particularly well-atuned pair, "would you mind showing me?" "Waiting for someone else to type," in my experience, is either a good opportunity to finish a bit of thinking that'd I'd put off moments prior, or else premeditate on our next move. Sometimes, however, the typing is, as you alluded to, an attempt to communicate something, in which case watching them type is roughly equivalent to listening to a person in conversation, and therefore an opportunity to learn, catch bugs, etc. In other words, when I am pair-programming I am never waiting qua idling. And, lastly, I completely agree that "somebody looking over my shoulder" is an unnerving condition to code under. As purely ergonomic concern, "over one's shoulder" is not a healthy position from which to operate a computer. ;) But, seriously, it's not pair programming if you're not on equal footing (seating?), with equal access to mouse, keyboard, and monitor. Don't stand for someone standing behind you! I am sorry for the unpleasant experiences you've had. As a practitioner, I would not have subjected you to them. I am, frankly, vicariously irritated with whomever did.
- breischl 3y ago"Looking over your shoulder" was just a figure of speech, not a literal description. And I suppose I could have grabbed the keyboard, but there's social niceties to navigate, everyone likes their keyboard & IDE set up different ways, and it's generally a PITA. Also the way I tend to code is never linear in a way that anybody else could follow. I write something, edit it, throw it away, put it back, rename it, hack out something I _know_ is buggy so I can see how it looks, and basically "thrash" my way to a solution that I like. That makes it essentially impossible for anybody to follow in real time, and having them try to point out errors would be counterproductive. In the later stages someone could help polish it, but even then I think it'd mostly be a waste of time. That's before we even get to things like dealing with interruptions, or answering other questions quickly. Ideally interruptions don't happen, but in practice they do, and I don't want to be wasting someone else's time. There's a lot I liked about XP, but I still think that (for some people) it's just a great way to make two devs produce the output of one intern.
- brailsafe 3y agoMeh, I don't think this is an intrinsic quality of working in the same space. Sometimes it is, if you're very lucky, but my experience in offices was mostly wasteful interactions with people who weren't satisfied with me checking my messages periodically instead of instantly.
- gavmor 3y ago> I don't think this is an intrinsic quality of working in the same space It's certainly not.
- urthor 3y agoI'd chew my arm off to have that 40h a week pair programming experience to be honest. Sounds like my dream job.