I was a Pivot - this article rings true. When I first joined people would often describe with joy how exhausted they were every single day for months when they first joined, as though it was evidence of learning and growth. That’s only true sometimes. What I realized is that it doesn’t actually stop being exhausting, people just adapt. There is a difference between being tired because I applied myself, did something meaningful and useful, and learned something new, compared to just being tired from navigating personal interactions all day every day.
The mortifying ordeal of pairing all day
251–260 of 308 posts
Re: The mortifying ordeal of pairing all day
#252I’ve had incredible experiences pairing. There were whiteboards, snacks, rating each other’s themes, and jokes. What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code. We’d then break away and work at our own speed and in our own style using the common foundation. Come together to integrate and discuss. Pairing is als…
I assume you are an extroverted person? Talking that much with another human being outside of someone I care dearly about just does not work for me, it just makes me anxious af. I'm glad it works for you and may you always another fellow extrovert to work. I left a job because they demanded pair programming as the new company paradigm. And yeah I gave it a shot for 3 months, and the other person was about as easy as…
Not at all. Excessive pairing makes me tired. And I, as many, loose my ability to type when someone is watching.
All in all, the actual pairing can be limited to 1h every few days. Done well it’s enough.
Demanding a work mode is stupid. Be it forced TDD, forced pairing, or forced welding when all you need is some glue.
Re: The mortifying ordeal of pairing all day
#253Is it really true that Pivotal had only n/2 workstations for the n devs? That seems to be an extreme arrangement (pardon the pun). I can see the benefit of pairing when
(a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the area well may be beneficial, because you get code-review while solving the problem. And your non-keyboarding partner can see things that you are too deep in to see.
(b) an interviewing technique to see how you collaborate and approach problem-solving (once again, there's an element of non-open-ended problem-solving here). I must hasten to add that this should not be the sole evaluation method in an interview, because many people can't collaborate impromptu with someone they do not know, and many people prefer to let their minds wander in search of a creative solution, which can look like cluelessness in an interview situation.
(c) inducting a new developer into a team: by watching a veteran at work and the techniques he uses, a new hire can quickly absorb best-practices that will bring his productivity to a high level in a relatively short time period. Once again, this must be done for shorter time-periods: it's pretty much impossible to maintain a high level of engagement with a problem for hours on end. Putting the problem in your back pocket, and sleeping on it often leads to flashes of insight that can deliver robust, clean code (the first system or solution to a problem is almost never the best, particularly in software or schema design).
I can't imagine many other scenarios outside of these, particularly for routine software development work, especially when code review by peers is a mandatory step in the process. You are probably removing the element of slow thinking, which can improve product considerably, by forcing pairing all day, every day.
How does such a wonky culture take root in a fairly large organization anyway? A lot of senior developers would just refuse to work for such an organization!
Re: The mortifying ordeal of pairing all day
#254Earlier quoted context omitted.
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.
I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.
Re: The mortifying ordeal of pairing all day
#255Earlier 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.
Code reviews sometimes seem like a micro-management tool: they often boil down to quibbling over things that are quite superficial, while simultaneously ignoring or missing big problems that lurk under the surface. Without some sort of automated linting and code style enforcement, this is what happens in code reviews. They serve as a reminder to the developer that his work is not trusted, and someone else must keep an eye on him at all times. This is very bothersome to people who have been around the block a few times, and are already capable of producing robust, clean product (this is often a pitfall of having someone who's just out of college reviewing code from an experienced dev).
Another problem I've observed in code reviews is that they turn into impromptu redesigning sessions. Most devs are quite opinionated, and code reviews often become an avenue to engage in bikeshedding that can actually harm morale, not to mention velocity and product quality.
The trouble with pairing is that it doesn't remedy these problems effectively, while simultaneously reducing the number of hands doing work. If two people just don't get along, pairing them is not going to magically solve the problem. And I guarantee that there will always be people who simply do not see eye to eye on many important things in most sizable teams.
Re: The mortifying ordeal of pairing all day
#256Earlier quoted context omitted.
Why not? For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things. 1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.
Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
Re: The mortifying ordeal of pairing all day
#257Earlier quoted context omitted.
> as a general rule it's only attractive to very mediocre engineers "Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.
...and then complain that there is a "shortage" of developers.
I think a developer presenting themselves as unqualified for the job, via being an asshole in a job that requires good communication skills and teamwork, you have a pass to say you have not gotten a qualified candidate yet.
Re: The mortifying ordeal of pairing all day
#258Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, eve…
> 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…
If you couldn’t figure out how to check your email or read documentation, it sounds like you were looking for reasons to fail. Pairing doesn’t mean you’re literally joined at the hip. You’re allowed to exercise judgment.
Re: The mortifying ordeal of pairing all day
#259Earlier quoted context omitted.
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".
Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.
In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said:
> No, one person is doing things, and another is watching and talking while the other person is doing things.
I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.
In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.
Re: The mortifying ordeal of pairing all day
#260Earlier quoted context omitted.
>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.
That seems pretty reasonable. I'd hate to work at a place that "didn't enforce" something, but had it turn into a 15 pieces of flair type situation.