Pair 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, ever. I work best within my own mind, and the distraction of talking to someone breaks my concentration such that I'm unable to keep the big picture in my head anymore. The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away).
There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.
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 Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force.
The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required.
It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches.
Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head).
The minute I need to communicate it, however, that efficiency goes right into the bog.
Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the value.
"A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high."
I have ADHD and pairing is liberating. I don’t need medicine, I can stay focused and motivated for years. I’m seriously worried that I’ll have to get back on medicine because the pairing opportunities in the industry are becoming so far and few between. If anyone has recommendations I’m all ears (and eyes)!
I’ve always encourage pair programming solely as a team cross training exercise and only for short stints.
Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.
That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.
Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.
>There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.
The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry.
Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!
> 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 client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.
> The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away).
For me the issue wasn't just the difference in frequency or duration of breaks, but also the fact that different people prefer to take breaks at different times.
In the end, unless you're very lucky, it ends up being a compromise for both parts and the productivity gains are negated by the constant context switching.
I think it's also fair to apply that tolerance to the team level: letting teams exist that require pairing. And teams that never pair. And everything in between.
That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations.
If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely.
The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.
I usually come off as a bumbling idiot when I try and pair program. It completely breaks the way my brain works trying to explain something while also trying to reason about a piece of software as a whole
How do you teach other people? In our team we sometimes have people working on systems that they are unfamiliar with, either because they are new to the team or new to the feature/system, and we've found that it saves a huge amount of time to have someone who is familiar with the system pair with them to get up to speed.
Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.
I've had great pair programming sessions in the past.
But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career.
I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!
In my experience, I've seen pairing work in the context of an experienced engineer mentoring a junior, as part of a spectrum of engagement: observing/reading, shadowing, pair programming, to then where the junior acts with more independence with some oversight, and then they're ready.
Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help).
In interviews for experienced roles, I might ask "what do you think of pair programming", and if they're positive about it there's a good chance I'll pass.
I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves.
The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MVP, code quality was abysmal and the product barely worked.
It stopped when the CEO took issue with it. He gathered the team to ask "why is the productivity so low?". There was an awkward moment where a junior dev was trying to answer but a tech lead was trying to tell him "don't break the rule".
It was an absolutely surreal experience, but not out of place in that startup.
EDIT: I also remember one of the tech leads complaining during a Sprint Retro that some of us weren't reading Slack fast enough, and we said "well, I was paring, I wasn't at my computer", to which he became a bit agitated and visibly angry. It was an awful place to work.
How did this rule maintain itself when essentially no one supported or agreed with it? (except the two 'leaders') Why wouldn't people take advantage of opportunities to push back against it, when for instance, the CEO asks what's the problem?
This sounds almost like the intentionally absurd example scenario described in Meditations on Moloch [1]:
> Imagine a country with two rules: first, every person must spend eight hours a day giving themselves strong electric shocks. Second, if anyone fails to follow a rule (including this one), or speaks out against it, or fails to enforce it, all citizens must unite to kill that person. Suppose these rules were well-enough established by tradition that everyone expected them to be enforced.
> So you shock yourself for eight hours a day, because you know if you don’t everyone else will kill you, because if they don’t, everyone else will kill them, and so on. Every single citizen hates the system, but for lack of a good coordination mechanism it endures. From a god’s-eye-view, we can optimize the system to “everyone agrees to stop doing this at once”, but no one within the system is able to effect the transition without great risk to themselves.
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 also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.
It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.
A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.
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 socialized different dev tools and terminal commands (I felt really smart when I taught a much more senior engineer about git push -u).
I also liked how it helped keep me engaged on days when I was tired and unfocused, and that the day was over at 5pm - you packed up and went home, and were disincentivized from doing more work until the next day.
Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase).
I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option to reduce costs is to have the customer supply half of the pair team, so I did this for a few half days one one project.
This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.
My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:
1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.
2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.
3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.
Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.
There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.
A few years ago, I worked on a project for about 11 months with one other guy and we paired almost all the time. Yes, it was mentally exhausting, yes we had some natural resistance to it at first. But damn was it effective, in producing higher quality code (two eyes on the code, two people to work out every problem or bug, always having someone to ping ideas off), in terms of knowledge sharing (we both understood every single bit of the code) and in terms of shipping on time. It was a complex project (reliably delivering large libraries of content to fleets of airplanes over satellite internet) and we delivered it from start to finish in under a year.
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.
The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns.
Pairing is incredibly useful and valuable, but doing it all day would be hell.
If someone told me that they wanted me to pair for the majority of my day, or even the majority of code I wanted to write, the first thing I would pair on would be a letter of resignation.
As an introvert myself, strong disagree. I (and introverts in general, to my knowledge) don’t have any trouble interacting with people in small group settings when those interactions are focused on ideas. The problems come with large group settings and small talk. Pairing is in the first category, not the second.
As someone who worked in an all pairing shop for two years (run by a bunch of former Pivots), I can confirm it’s pretty draining, though my experience wasn’t nearly as bad.
I actually liked pairing a lot of the time, and still think it’s an excellent way to onboard into a new code base, even in a non pairing shop (I even miss it sometimes!). For me, the main drawback after a while was that I felt like I was less efficient when pairing on stuff I knew how to do, and my personal growth as an engineer was stunted because I could always lean on a more experienced pair. Since that was my first eng gig, my second job had quite a steep learning curve as I had to figure out how to debug and navigate on my own, without talking through it out loud.
I worked for a couple of years on a company where we had a "pair-up all the time" when working and... We were very aware it wasn't possible to keep up like that 8h/day every single day. Most days we were very happy with 4 hours, really productive (and exhausting) days were around the 6 hours mark.
We made sure to take breaks every 45 min-1h30 (depending how well the session was going), those breaks could be from 10 minutes to an hour, it needed to make us feel refreshed, not talk to people if needed, etc.
I actually miss this setup a lot, it was much easier to not feel stuck, much better to have a peer available all the time to bounce ideas, clear assumptions, discover the codebase, etc., but I couldn't ever do it 8 hours/day.
I did it for 11 months (see comments elsewhere here) and I found it was both effective and rewarding.
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.
Honestly reading that felt extremely anxiety-inducing and like a nightmare work culture. My work patterns are too chaotic to ever pair for more than an hour if I’m forced to.
I worked for a shop that adopted the Pivotal model and I can say that it was hell on Earth. If you check the research data it is obvious that pairing is only effective in some very special cases like: knowledge transfer for new teammates, onboarding people, getting juniors up to speed, solving __very__ complex problems. For your everyday work it is not only draining, but also a waste of both of your time. What makes it even worse is that your downtime will double because of pee breaks, coffee breaks, lunch breaks. People rarely feel the need to go at the same time. Nowadays if I'm interviewing somewhere one of my first questions if they have adopted this madness or not.
Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every day.
I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.
8+ hours is not okay not every other day or even less frequently. Ok, once in a while is ok if one is in a good rhythm and they are enjoying themselves. But after 4-6 hours productivity drops sharply and starts to erode from the following days: fixing up poorly made design choices, etc
If your employer expects you to be productive 8 hours a day I’d look for something else
I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.
There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits to both productivity and morale. One advantage that was emphasized in the interview was that people were no longer distracted by non-work concerns like who would pick the kids up after school or needing to book medical appointments in the middle of the working day. With shorter working days and everyone being around during the same hours, collaboration and maintaining focus were also easier.
> I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.
It might be possible, but it definitely would not be acceptable!
When I started my first job programming job out of university, I spent a lot of time pairing with one of my teammates (online) at the beginning. Not necessarily because it was enforced, but I think we figured it would just be a good way to learn. This went on for a few months, over time I'd take shots at doing tasks for myself, some with more or less success.
Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.
Project management is fundamentally about managing human psychology. This is a horrifying prospect, because we do not truly understand human psychology at a mechanistic level, much less to the point where it can be applied to the individual.
Therefore, we instead seek refuge in processes and rituals that are, for practical reasons, not validated by experiment. One can hide almost any issue in a forest of obtuseness. If something doesn't work out, one can always blame it on some failure in adherence to the dogma.
Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc.
I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing.
Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.
--
As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.
It is just a different way to achieving the outcome.
If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.
But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.
So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.
I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.
--
I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.
Is it just me or is it trivially easy to get all the benefits the author describes without the downsides? Maybe just do it fewer hours for fewer days. Build in enough time for full recuperation. I'd say half as many workstations as people is definitely asking for trouble.
There's also the other extreme, Mob Programming, where you get everyone in a room together with one projected screen.
The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.
First off - I feel terribly sorry for the author's experience and I can totally empathise to it. Also want to share my personal experience and some mitigation techniques.
I was pairing 8+ hours per day from 2012-2017 with 10+ engineers in total, most of that time fully remote. My company highly praised Pivotal and its processes, specifically pair-programming. Similar to the author, I have experienced different levels of engagement from my peers, conflicts, etc. I can 100% agree that pair-programming is extremely physically/mentally exhausting. Even just to talk for 8 hours/day puts your brain under extreme pressure. Here are some of techniques I've learnt and employed to mitigate the negative consequences:
* Talk through the pros and cons of pair programming with your new pair upfront. Ideally have your thoughts on the topic already written in a doc. E.g. clarify the difference between the dynamic: person behind the keyboard (driver) is generally thinking slower (spends time on typing), while the observer have more time to think. Explain the importance of switching the driver regularly. Explain the benefits of being the driver: e.g. if a person wants to build up the context in a new area it might make sense to be the driver and learn at slower pace. Ideally switch the driver every day.
* Agree on the scheduled regular breaks. E.g. I used to have a pomodoro timer for 45 mins and then a 10 mins break. When working from office having a game of ping-pong/pool is a great idea. When remotely just switch off from the computer to relax a bit. This also helps with distractions (e.g. Slack, Email, etc): use that time (and only that time) to manage the distractions so that you can have your full focus while pairing.
* Do frequent retrospectives and give feedback. At the end of the pairing day ask "What did you like/did not like?". Try to be honest: it is important to catch factors that irritate/annoy early and fix them rather than letting them grow into a bitter relation.
More importantly be inclusive: pair programming just doesn't work for everyone, there's no point to force someone in to it. It is worth a try though. I find its benefits hugely overweigh the downsides.
It takes a long time to get over the kind of Stockholm Syndrome an employer like this creates. The OP is at the first stage: disengaging and trying to get perspective. At some point hopefully they will see that they were being psychologically manipulated to meet a corporate goal without any concern for their individuality. That to me is the definition of a bad employer: they want units not humans.
[+] [-] kstenerud|4 years ago|reply
I played along and paired for awhile, but now steadfastly refuse to pair, ever. I work best within my own mind, and the distraction of talking to someone breaks my concentration such that I'm unable to keep the big picture in my head anymore. The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away).
There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.
[+] [-] ChrisMarshallNY|4 years ago|reply
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 Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force.
The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required.
It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches.
Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head).
The minute I need to communicate it, however, that efficiency goes right into the bog.
[+] [-] harryf|4 years ago|reply
There is this study here - https://www.researchgate.net/publication/222408325_The_effec...
"A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high."
There are links to a few more here - https://tuple.app/pair-programming-guide/scientific-research... - none of it looks particularly compelling.
And I'm not "against" pair programming. It's just sad to see "cargo cult" adoption of practices.
[+] [-] superduperycomb|4 years ago|reply
[+] [-] brightball|4 years ago|reply
Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.
That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.
Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.
[+] [-] goatcode|4 years ago|reply
The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry.
Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!
[+] [-] commandlinefan|4 years ago|reply
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 client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.
[+] [-] ratww|4 years ago|reply
For me the issue wasn't just the difference in frequency or duration of breaks, but also the fact that different people prefer to take breaks at different times.
In the end, unless you're very lucky, it ends up being a compromise for both parts and the productivity gains are negated by the constant context switching.
[+] [-] ballenf|4 years ago|reply
That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations.
If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely.
The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.
[+] [-] athorax|4 years ago|reply
[+] [-] jhedwards|4 years ago|reply
Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.
[+] [-] eloisant|4 years ago|reply
But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career.
I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!
[+] [-] eplanit|4 years ago|reply
Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help).
In interviews for experienced roles, I might ask "what do you think of pair programming", and if they're positive about it there's a good chance I'll pass.
[+] [-] ratww|4 years ago|reply
The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MVP, code quality was abysmal and the product barely worked.
It stopped when the CEO took issue with it. He gathered the team to ask "why is the productivity so low?". There was an awkward moment where a junior dev was trying to answer but a tech lead was trying to tell him "don't break the rule".
It was an absolutely surreal experience, but not out of place in that startup.
EDIT: I also remember one of the tech leads complaining during a Sprint Retro that some of us weren't reading Slack fast enough, and we said "well, I was paring, I wasn't at my computer", to which he became a bit agitated and visibly angry. It was an awful place to work.
[+] [-] audiometry|4 years ago|reply
How did this rule maintain itself when essentially no one supported or agreed with it? (except the two 'leaders') Why wouldn't people take advantage of opportunities to push back against it, when for instance, the CEO asks what's the problem?
[+] [-] wilsonrocks|4 years ago|reply
It's amazing how workplaces can get in these kind of darkly comic places
[+] [-] Sharlin|4 years ago|reply
> Imagine a country with two rules: first, every person must spend eight hours a day giving themselves strong electric shocks. Second, if anyone fails to follow a rule (including this one), or speaks out against it, or fails to enforce it, all citizens must unite to kill that person. Suppose these rules were well-enough established by tradition that everyone expected them to be enforced.
> So you shock yourself for eight hours a day, because you know if you don’t everyone else will kill you, because if they don’t, everyone else will kill them, and so on. Every single citizen hates the system, but for lack of a good coordination mechanism it endures. From a god’s-eye-view, we can optimize the system to “everyone agrees to stop doing this at once”, but no one within the system is able to effect the transition without great risk to themselves.
[1] https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
[+] [-] raverbashing|4 years ago|reply
Funny, that would be the easiest way to get me to stand into a desk and make a "liberating speech", then drop the mic and leave the company.
That is not a development practice, it's a cult
[+] [-] abledon|4 years ago|reply
[+] [-] gherkinnn|4 years ago|reply
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 also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.
It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.
A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.
[+] [-] jmcgough|4 years ago|reply
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 socialized different dev tools and terminal commands (I felt really smart when I taught a much more senior engineer about git push -u).
I also liked how it helped keep me engaged on days when I was tired and unfocused, and that the day was over at 5pm - you packed up and went home, and were disincentivized from doing more work until the next day.
Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase).
[+] [-] chrisBob|4 years ago|reply
This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.
My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:
1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.
2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.
3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.
Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.
There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.
[+] [-] UweSchmidt|4 years ago|reply
Red flag for all kinds of weirdness if you're made to take on a company-based identity.
[+] [-] dkersten|4 years ago|reply
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.
[+] [-] pavel_lishin|4 years ago|reply
The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns.
Pairing is incredibly useful and valuable, but doing it all day would be hell.
If someone told me that they wanted me to pair for the majority of my day, or even the majority of code I wanted to write, the first thing I would pair on would be a letter of resignation.
[+] [-] redisman|4 years ago|reply
[+] [-] jdlshore|4 years ago|reply
[+] [-] naomiajacobs|4 years ago|reply
I actually liked pairing a lot of the time, and still think it’s an excellent way to onboard into a new code base, even in a non pairing shop (I even miss it sometimes!). For me, the main drawback after a while was that I felt like I was less efficient when pairing on stuff I knew how to do, and my personal growth as an engineer was stunted because I could always lean on a more experienced pair. Since that was my first eng gig, my second job had quite a steep learning curve as I had to figure out how to debug and navigate on my own, without talking through it out loud.
[+] [-] MattGaiser|4 years ago|reply
[+] [-] piva00|4 years ago|reply
We made sure to take breaks every 45 min-1h30 (depending how well the session was going), those breaks could be from 10 minutes to an hour, it needed to make us feel refreshed, not talk to people if needed, etc.
I actually miss this setup a lot, it was much easier to not feel stuck, much better to have a peer available all the time to bounce ideas, clear assumptions, discover the codebase, etc., but I couldn't ever do it 8 hours/day.
[+] [-] dkersten|4 years ago|reply
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.
[+] [-] simonmales|4 years ago|reply
When one is loosing focus, there isn't a hesitation to say let's take a break. I found it similar to taking a timeout in basketball.
As an engineering manager I stressed it to the team. Take breaks or you will break.
[+] [-] enw|4 years ago|reply
[+] [-] edem|4 years ago|reply
[+] [-] nikanj|4 years ago|reply
I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.
[+] [-] tartoran|4 years ago|reply
If your employer expects you to be productive 8 hours a day I’d look for something else
[+] [-] Silhouette|4 years ago|reply
There have definitely been experiments along those lines with successful results. I can't immediately find the original source, but I remember reading a few years ago about a business that switched to working 9-3 Monday-Friday, with resulting benefits to both productivity and morale. One advantage that was emphasized in the interview was that people were no longer distracted by non-work concerns like who would pick the kids up after school or needing to book medical appointments in the middle of the working day. With shorter working days and everyone being around during the same hours, collaboration and maintaining focus were also easier.
[+] [-] admissionsguy|4 years ago|reply
It might be possible, but it definitely would not be acceptable!
[+] [-] Ashanmaril|4 years ago|reply
Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.
[+] [-] incrudible|4 years ago|reply
Therefore, we instead seek refuge in processes and rituals that are, for practical reasons, not validated by experiment. One can hide almost any issue in a forest of obtuseness. If something doesn't work out, one can always blame it on some failure in adherence to the dogma.
[+] [-] lmilcin|4 years ago|reply
Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc.
I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing.
Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.
--
As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.
It is just a different way to achieving the outcome.
If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.
But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.
So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.
I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.
--
I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.
[+] [-] andrewflnr|4 years ago|reply
[+] [-] imglorp|4 years ago|reply
The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.
https://mobprogramming.org/
[+] [-] gregolsen|4 years ago|reply
* Talk through the pros and cons of pair programming with your new pair upfront. Ideally have your thoughts on the topic already written in a doc. E.g. clarify the difference between the dynamic: person behind the keyboard (driver) is generally thinking slower (spends time on typing), while the observer have more time to think. Explain the importance of switching the driver regularly. Explain the benefits of being the driver: e.g. if a person wants to build up the context in a new area it might make sense to be the driver and learn at slower pace. Ideally switch the driver every day.
* Agree on the scheduled regular breaks. E.g. I used to have a pomodoro timer for 45 mins and then a 10 mins break. When working from office having a game of ping-pong/pool is a great idea. When remotely just switch off from the computer to relax a bit. This also helps with distractions (e.g. Slack, Email, etc): use that time (and only that time) to manage the distractions so that you can have your full focus while pairing.
* Do frequent retrospectives and give feedback. At the end of the pairing day ask "What did you like/did not like?". Try to be honest: it is important to catch factors that irritate/annoy early and fix them rather than letting them grow into a bitter relation.
More importantly be inclusive: pair programming just doesn't work for everyone, there's no point to force someone in to it. It is worth a try though. I find its benefits hugely overweigh the downsides.
edit: formatting
[+] [-] scandox|4 years ago|reply
[+] [-] denkmoon|4 years ago|reply