91–100 of 308 posts
"We were Pivots, and one of the things that made us Pivots was that we paired." Red flag for all kinds of weirdness if you're made to take on a company-based identity.
How the heck can people work like that for 8 hours? I start to get very worn out at 2 hours of conversation.
It is tiring. Some people don't like it. Evidently, it burns some people out (i paired for about eight years and didn't burn out). But some people get on okay with it. And when it's done well, it really is extremely effective.
It seems interesting but rather inefficient since you can just do things faster than explaining them to someone and having them do them. It seems like it would only be good on tasks where having your partial work continuously reviewed is very valuable.
Earlier quoted context omitted.
Yes, that's how pairing works: two people, one keyboard, one workstation. Having done this for a while, I wholeheartedly agree with everything the author says. It's great for software quality and productivity (among other things, it's much harder to slack on HN), but it's also incredibly draining and definitely not for everybody.
Two people, TWO keyboards, one workstation (with a good monitor). You can't keep switching seats, or shuttling the keyboard back and forth. Remove as much unnecessary friction as possible. And assign someone on the team to be the tea-mug refiller for the day. And management have to provide a workstation for each worker; you pair at a pairing workstation, but everyone needs their own machine for stuff like email, Slac…
I think the Pivotal way is significantly worse - you have a physical machine to yourself, but not a logical machine, so there is a base level of confusion. Sharing a single keyboard means that it's always obvious who is driving. Sharing a single screen means you can gesture at things.
Rather than giving everyone a machine, you can have a few spares for doing email and other solo stuff (as long as you are using webmail!). If people are pairing most of the time, you don't need a dedicated machine each.
Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…
Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.
* Having multiple perspectives on design.
* Having an extra pair of eyes to catch things one person might miss.
* Being able to bounce ideas off each other.
* Redundancy (if you are on holiday or sick somebody else still knows the code deeply)
* Onboarding (it works better at getting me up to speed than any docs ever have)
* Motivation (i find it's kind of like having a gym buddy).
* Bonding (assuming you get along with whomever you're pairing with)
I get that not everybody likes it though.
I feel that it's somewhat irksome for introverts and companies try to use it as a means of making developers more replaceable, which some people hate.
Some mornings I would wake up and really not want to pair, but I'd do it anyway because its what we agreed we'd do, and after an hour or so, I got over it and we were super productive. Sometimes I miss it, especially since I'm mostly working on my own these days.
I don't work there anymore, but last I checked with former colleagues the code was still ticking along in production with no issues.
When pairing, its important to take regular breaks and also to not overdo it (don't work overtime). It IS mentally draining. Most people are also naturally resistant to the idea and I don't think it can work unless all involved people buy into it. But I found it was the most effective way I've ever worked and also quite rewarding.
Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…
Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.
I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production without issue years later. We paired every day for about 11 months.
Yes, its mentally exhausting. You need to take regular breaks. You also need buy in from everyone involved, if one person is half-assing it, its going to fall apart.
The benefits I saw were many: better quality code (two sets of eyes on the code at all times, two people solving every problem or bug, always someone to ping ideas off), better understanding of the code/knowledge sharing (both of us fully understood every line of code written, why it was like that, what it was for), shipping on time (easier to make decisions to get it production ready quickly when two brains are working on it, easier to avoid bugs, boring tasks like documenting are easier too).
I don't think the project could have been completed in the time it was with only two people if we hadn't paired. There was also no disparity in experience or seniority, we were both quite equally matched.
How the heck can people work like that for 8 hours? I start to get very worn out at 2 hours of conversation.
Some key points are that helped me:
1. You have to get on well with the person/people you're pairing with. You're working very closely with them, after all.
2. You have to take regular breaks. Pairing is mentally exhausting. But its not like 2 hours of conversations, we often sat there one person driving and being silent, the other person watching and making suggestions or pointing out issues. Usually when we needed to have actual discussions we would step away from the computer to do so. We also worked remotely a lot (I miss screenhero...) which probably also helped.
3. We never did overtime. We worked what the contract said and then no more work whatsoever. You need your downtime to recharge. We also usually went outside for lunch, to get a change of scenery and some air to clear our heads. (When we were in the office, when working from home, I dunno what the other guy did)
4. Sometimes you need some alone time to think, separate from a break. That's ok, take the time. Just make sure you both stop coding during this time. If the other person doesn't need time to think, they can go for a coffee or jot down the next tasks to tackle while coding. Or go for a walk.
5. When one person is out (sick, holidays, whatever) obviously the other person can't just sit around doing nothing. But when the other person is back, spend a day just doing code review with them so they can see what you did and why.
6. You need buy-in from all involved. In my case, it was a team of just me and another guy on that project. We were the ones who decided to try it, nobody told us to do it and we weren't forced to.
Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot , quickly, from working with senior engineers and seeing how they approached problems or building systems. You even…
Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.