Several paragraphs in, and still hasn't defined "pairing."
NEXT
The mortifying ordeal of pairing all day
231–240 of 308 posts
Re: The mortifying ordeal of pairing all day
#232Earlier quoted context omitted.
> but rest assured that there are those who aren't built that way Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail…
I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely. If terminal based pair programming doesn't work, Visual Studio Code…
They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/
I have yet to try it out though.
Re: The mortifying ordeal of pairing all day
#233Earlier quoted context omitted.
I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging )
I do this. It works. I have a stuffed parrot though. And everyone thinks I’m nuts but I don’t care :)
Re: The mortifying ordeal of pairing all day
#234Earlier quoted context omitted.
Pairing is also, bar none, the best way I've seen to onboard a new hire. There is no better way to learn a codebase than to work closely with someone who knows that codebase, on a real-world, production problem.
Yeah. I almost want to say it's the only realistic way to onboard. Depending on the codebase, I feel it's literally 10-50x more productive.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
Re: The mortifying ordeal of pairing all day
#235If your programming routine is causing someone to go on short term disability because it has caused them significant mental impairment, why was there never a discussion about perhaps too much of a good thing is now damaging our workers? Like, nobody thought to themselves, this is causing actual damage to our workers, and maybe we should scale it back?
It's very hard to imagine how other people experience it, because people's experiences can be so wildly different. My wife can carry on conversations while solving problems and getting her work done. It helps her think. She can also talk all day, quite literally, conversing without pause from the moment she wakes up until the moment she closes her eyes, without feeling that it takes any extra energy. If anything, talking is a bit easier than not talking, and it frees her brain to work more creatively and systematically.
Me, I'm exhausted by conversations that last more than a few minutes, and talking interferes with my ability to think. I have to tell my wife sometimes, "Look, I know you shared this new piece of information with me half an hour ago, but we've been talking about it the whole time since then, so I haven't processed it at all. I don't know how I feel about it. I haven't thought about how it changes things. I'm just trying to force out utterances at the expected conversational rhythm until we stop talking and I can engage with the new information."
These two experiences are so far apart that it's very hard to comprehend someone on the other side. In fact, I think it's even harder for someone like my wife to understand someone like me, because I've had it drilled into me from a young age that my way is not the normal one. Lots of people seek professional help because they are too much like me and want to be more "normal" like my wife. Vice-versa, not so much.
My wife loves me and has been living with me for almost five years, but she is still working to internalize the fact that these differences are real. She still has to fight with her gut-level assumption that I experience conversation much like she does, and if I don't partake, it reflects hostility or indifference, and if I say I can't, I'm malingering. If she still has to consciously override that reaction, imagine a management layer of extroverts whose only exposure to introverts is through managing them. To them, it just looks like some people are adapting and thriving, and others are obstructing and malingering.
Re: The mortifying ordeal of pairing all day
#236Earlier quoted context omitted.
Yeah. I almost want to say it's the only realistic way to onboard. Depending on the codebase, I feel it's literally 10-50x more productive.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
Oh yeah. I've been there multiple times. I meant the only realistically productive way.
Re: The mortifying ordeal of pairing all day
#237Earlier quoted context omitted.
And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
Re: The mortifying ordeal of pairing all day
#238Earlier quoted context omitted.
I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
I have mixed feelings about code reviews. It seems like sometimes they're an opportunity to show off so every review _will_ find something insignificant; sometimes code reviews are rubber stamps and just not useful. There's a balance though where you get concise thoughtful responses.
It seems like there is something about pairing though that guarantees a focus on shallow insignificance. I don't like dismissing something that has smart proponents but I just can't find a way to make pair programming anything other than negative. The real time aspect rules out depth.
Re: The mortifying ordeal of pairing all day
#239Earlier quoted context omitted.
Pairing works great; as long as everyone is on the same "wavelength." That's absolutely vital , and has both good and bad sides. The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Mar…
Just a word about the Marine analogy in case some manager sees this and gets all excited: Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature. It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enorm…
> Team work is much more natural if you are up against an external enemy in the broadest sense
This is why I've always found it frightening when some management type starts talking about the book Extreme Ownership. I am a veteran, though I was not SOF, and I have strong opinions about why military management mindsets do not translate well to the business world in _most_ cases. To be fair, I have not read the book, but from what I have heard from those who have read it, I would be wary of anyone trying to apply it to a software engineering shop.
Re: The mortifying ordeal of pairing all day
#240Earlier quoted context omitted.
Pairing is optional at my employer. As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers. I have also managed people who just like to work together and they're free to pa…
>Pairing is optional at my employer. Is collaboration / pairing part of employee evaluation in any way?
Not directly. If somebody actively avoided paired work, I'd probably ask them about it during a regularly scheduled 1-on-1. And if somebody was doing a spectacular job mentoring/pairing/etc I'd definitely mention it.