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, Slack, and reading the news over lunch.
Bring a notebook, and record the work you are doing with your pair. You will need that information for the next-morning's SCRUM.
In my team, the rule was that one person was "driving" (hands on keyboard) and the other was "navigating" (hands off). Whether there's two physical keyboards or not is kinda of immaterial.
Traditional pairing uses one keyboard, and one screen (or one pair of screens, etc). When i went to Pivotal, that was the first time i had seen two keyboards and mirrored screens.
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.
I often did remote pairing over screenhero some years ago. We just got really good at communicating with each other who gets to type and who has to keep their hands off. The first few weeks were hard, we'd naturally just try to fix a typo or something and end up conflicting, but after a short while we got into a nice groove and it was never a problem again.
When I did pairing (see other comments of mine), we used our own laptops. That way, we could both have our own setups that we were comfortable in. It did mean that switching often consisted of a git commit to our branch that we later squashed out.
We didn't always bother switching laptops though and we also worked remotely about half the time (using screenhero at the time, I miss SH).
> And assign someone on the team to be the tea-mug refiller for the day.
I disagree with this. I found frequent breaks to be very important. Pairing is exhausting. "Lets get more tea/coffee" was a good way to have a short break. I think frequent breaks also made using different laptops easier, since its natural to switch drivers after a short break. We didn't have breaks on every switch, of course, but on many we did. The breaks were often only a few minutes, but getting away from the screen even for three minutes really helped.
I occasionally pair with someone, though it's not enforced or even suggested in any way, just a result of discussing a problem for long enough that one of us says "wanna pair on this?".
We use either tmate (a fork of tmux specifically for pairing) or a VSCode plugin, depending on whether what we're pairing on.
I quit my job when pairing was introduced. I was open to the idea when I read about it but hated the reality. Everything from working 12 inches from people who refused to use deodorant to having to explain what I was thinking instead of just doing it. Also all my tools, preferences, keyboard shortcuts, etc. were mine, committed to muscle memory over years, and nobody else's setup was the same. Didn't work for me.
What is it with people in our field that this is so commonplace? There are few things worse than a room full of IT people with the windows closed. "It's the smell" as Agent Smith said.
btw, you may not be the problem, it's more likely it's your clothes. I had this problem for years, I was basically smelly 30 minutes after a shower and a fresh set of clothes.
I then learnt several tricks on how to wash my clothes properly, and the problem has gone away completely. Butyric acid stays in your clothes for a long, long time unless you use the right chemicals. I went from horribly smelly guy to no odour overnight.
I now soak all my T-shirts in a bucket with baking soda, rinse them and then put them in another bucket with diluted vinegar, then finally, normal wash. If you have white "pit stains" from deodorant, you want to clean that stuff off. There are special cleaners for that. I do this once every 6 months, and it's enough to keep it all fresh.
Being smelly all the time is a major knock to your self confidence and self image, it's worth the 30 minute hassle twice a year!
I stopped using deodorant years ago because I just didn't see the point.
If it did what it said on the bottle I'd be fine with it, but it doesn't actually deodorise anything. If you or your clothes are dirty the only way that takes away the smell is to wash, adding another smell on top of it is not a solution.
If they want to make a deodorant they should sell bottles of chlorine gas instead, but then they'd have to answer to the OPCW, never mind the FDA.
you want anti-perspirant, not deodorant. Try Mitchum Unscented (It's for "women" but it's completely odourless, so who fucking cares). It's BY FAR the best deodorant I've ever found. As someone who used to suffer from serious BO; find a product that works, and learn to wash your clothes properly. Butyric acid is the enemy.
Yeah, I suspect what makes people smell bad is not so much the sweat as organisms that spring to life in their clothing when exposed to sweat, or just plain water for that matter.
Before the pandemic I worked with a lot of lycra biker types who would bike in and then shower at the office, and their wet towels made the whole office reek to high heaven. I mostly don't care about people's actual BO, but I suspect that I'm very sensitive to certain fungal VOCs. They give me migraine-like symptoms. I know some hoarders who haven't taken a shower in years, there's a kind of penile and scrotal aura in the air around them. It's not pleasant, but it's not even on the same scale as mouldy towels and clothes.
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 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.
6 solid hours of coding solo is pushing my daily limits. I can do more but productivity goes down. Day in day out pair coding sounds for 6 hours sounds more intense again.
> 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.
They can't. That's how the author got burned out.
To my experience PP is to a large extend a way (for the management) to make sure that people are not slacking. As for the burnouts...
It's not like a conversation. It's like doing a task together. You're focused on the work, and most of the time, you're giving each other small nudges, rather than having a conversation. Not all the time. It's hard to explain.
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.
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.
I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with the inevitable conflict resolution, even if that's not your job. Even if your pair shows only for a couple of hours a day and you have to do the work of two people.
“Much harder to spend time on HN” people who like pair programming either like to have power over someone else, or they want to coast and/or be handheld.
People say it's about collaboration... it's more about learning power phrases like “let’s timebox this exploration”, “you have to call the keyboard”, “let’s do plus and deltas”.
I tolerate it because the productivity is so low it helps recovering workaholics.
It's the best secret to dilute accountability and charge outrageous consulting fees.
If it is like workplace Stasi and like the movie Brasil, shouldn't we expect pairs to slack off together in conspiracy, watching movies like in Brasil or commenting on HN instead of working. Does pair programming cause dysfunction?
Also, is there a pair programming equivalent of the Scrum Master? That would be the chief slack position.
I liked pairing. I was pairing for about three years, 09:30 to 17:00, with an hour for lunch.
It certainly is exhausting. It certainly produces better code. If you pair and rotate, then after a number cycles, everyone in the team knows the codebase.
There is something a bit weird about XP. It looks as if coders are being given control, and they are; but they manage themselves even more sternly than their management would have. That is, coders seem to demand more of themselves than even aggressive managers.
Everyone knowing the codebase is also a way for developers to shoot themselves in the foot; when everyone knows your job, it becomes easier for you to be replaced.
I'm not a master programmer - at best, I was a journeyman. I learned a lot from the people I paired with, about half of whom were better than me. I only paired with two guys that I found really difficult; one was a good programmer, but had quite severe asperger's. The other was a reckless, entitled idiot, and pairing with him amounted to trying to stop him writing any code.
I'm not familiar with those "power-phrases". And I never encountered power games. I guess we all had enough confidence in ourselves and our colleagues that we didn't feel we had to prove anything. We respected one-another. Well, I certainly respected (most of) the other team members.
In a disfunctional team, I guess pairing can only make things worse.
Regarding diluted accountability: I found the oppposite. At the morning SCRUM, you have to give an account of what you did yesterday. You can't make it up, because your pair is at the SCRUM too. And the evidence is in the commit log.
And I didn't find that productivity was low. I'd say that functionality was delivered at about 75% the velocity of solo work, but the code we delivered was much better quality, so maintenance and bug-fixing was massively reduced.
I was working with a team of rather good people; I imagine pairing might be a lot more tedious and unproductive if the majority of the team are dim, incompetent, socially maladapted, or psychopathic. But then the same applies to solo coding.
> People say it's about collaboration... it's more about learning power phrases like “let’s timebox this exploration”, “you have to call the keyboard”, “let’s do plus and deltas”.
I sense that you might be saying those phrases can be used to manipulate the other half of the pair. For the first one, I can speculate: The pair disagrees how to approach some problem, then one of the two suggests to “timebox an exploration” into their favorite approach, and then after spending an hour on it (or whatever), the code is already there and nobody wants to delete it again.
But what do the other two phrases even mean, and how would they be used to manipulate?
This is a place that starts the day by sounding a gong so they at least wear the cult-y-ness on their sleeve.
I think this is one of those things that is going to work for some and not work for others.
I quit very quickly after being subcontracted into Pivotal. I need quiet focussed periods of inner monologue to turn over problems. I can't talk and think.
Other people think by talking. I suppose artificially limiting the types of people who work for you is a choice of some kind
> Over time, over years, pairing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.
This can be true of any demanding job.
Pairing is like running or cycling together. One person will be faster or have more endurance than the other. The slower one must set the pace or they will get exhausted quickly. For sustainable daily pairing, I would expect the team to quickly develop a hierarchy of speeds, with the lower speed person in every pair controlling the console.
It's true that the slower person should set the pace; unfortunately that doesn't always happen. I found that some of my pairs were so much faster than me, that they had to spend quite a lot of time explaining what they were doing - I was slowing them down.
But with rotation, it won't be more than a couple of days before you're paired with someone more closely-matched to your abilities.
That's not true in my experience. I also participated in such an "experiment" and I'm normally the one with more endurance and speed, able to do overtime, or work on personal projects after hours.
In my experience, with daily pairing, both workers felt completely drained of energy after 4 hours (including pauses).
Pairing a couple hours a day, or a couple times a week is alright, and very productive. Doing it 5 days a week is borderline inhumane.
Having the same supper feels more of a way to avoid stress, to avoid making multiple decisions daily, to have some grounding in your life, to have less risk. Similar to Steve Jobs wearing the same uniform everyday to work. [1]
As said in other post in this thread, by Cthulhu_, part of the appeal of pairing is "getting out of your comfort zone". I don't think this guy wants to be out of his comfort zone for 8 hours a day.
If he were a coder, maybe "stability" would be working solo. Maybe he would have liked 8hrs/day pairing. Maybe he'd prefer start his coding around 6:00 and going home after lunch. No way of knowing.
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.
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.
Well, you can, but you'll annoy people even more than if you had a mechanical keyboard ;) I do have a little needle-felted rubber duck I keep on my desk while working, remotely, though, for just that reason.
Agreed. I think pairing basically amplifies the team chemistry, for better or worse. If you have down-to-earth developers who like to learn and teach and generally get along, pairing will be amazing, but if you have know-it-all devs desperate to be right and show how smart they are, it’s a disaster. I paired for a year in the latter environment and it was miserable.
I had a very positive experience pairing for 11 months, but yes, it was a team of just two of us on the project, we got on well, and we were the ones who decided to try pair programming. Nobody forced us to or told us 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.
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'm not so surprised that they got such good results in Japan, where traditionally the business culture has been extremely demanding compared to most places. It would be interesting to know whether they did ever try similar experiments in other parts of the world with more "normal" working hours, and if so, whether they managed to repeat the successful result.
The Japanese work ethic of working yourself to the bone is puzzling to me. A culture driven by deep traditions, they need to stop once in a while and re-evaluate some. Not all traditions are worth keeping, like working all day every day, or using fax machines - another tradition that is refusing to die in Japan.
I agree. If I'm working on something particularly interesting, I can code for much longer for a day or even a few days and still be making useful progress. However, for routine grunt work over the long term, I don't think I ever sustained much more than 6 hours of productive work per day when I was programming full-time. Past that, I would start to either slow right down or make mistakes that ended up taking more time to fix later. I did find that as I started taking on other responsibilities as well as the technical stuff I could make use of the extra time for that without affecting my programming much, but I suspect if I ever move to full-time on the business side the lack of variety will be a factor again.
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
This is something that I find very hard to explain to non-technical managers when I run dev teams.
There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better.
There's also the bullshit long-hours work culture where leaving work before the boss does is somehow unacceptable.
The best approach I've found is to explain that the codebase is an asset that can be damaged. And the code itself is a liability - it must be maintained in the face of changing requirements and technology. "More code" is worse, not better, for the company. So having tired developers write bad code is both damaging our asset and introducing more liabilities. We need our devs rested and on their game to avoid that. We need them thinking deeply about the code they're going to write. And that thought doesn't have to occur at the keyboard. Good devs think about their code while going about the rest of their lives.
It's better if a tired dev goes home to rest rather than continuing working on the code, because they'll just end up damaging it if they work on it tired.
It's better for a dev to go for a walk to think deeply about what they're doing rather than write code that they're not sure about.
We don't want devs working on the codebase after ~8 hours, because they probably haven't thought enough about what they're writing.
It can work. Depends on company culture.
There's also so much bullshit in dev culture itself about "marathon hacking sprints". I bought into this myself, did a 32-hour sprint to meet a deadline. It was a complete mess. I would have been so much better off getting some sleep, a decent meal, and going for a walk in the middle. I think most devs go through this lesson at some point.
I get the point. In terms of accounting principles, you're right, technically.
But it doesn't drive home the message that more code doesn't mean more asset. Having a developer write more code doesn't automatically create more value. The value is in what the code does, not the code itself. And a developer can actively harm the codebase by working on it. You can pay someone to improve it, and the end result is a decrease in value, not an increase. I'm not sure there are other asset classes that behave the same way. I could be wrong.
> 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!
Yeah, this sort of behavior should make anyone cringe. I understand that you want to encourage team spirit and build cohesion, but jfc pump the brakes. Reminds of the Noogler hats[0] that screams "I'm New Resource no. 348, bear with me as I assimilate".
I once protested against the cult description and then someone pointed out that I did the 3-2-1 clap whenever my team finished an IPM or retro.
Pivotal definitely had an incredibly strong cultural field strength. That much it shares with cults. Personally, I loved it, like anyone who finds a fit in such a place.
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.
This was a very strange workplace. Its atmosphere was half frat-like and half cult-like.
There was literal chest beating and shouting motivational stuff during sales meetings, an incredibly amount of beer (which isn't necessary an issue, but in this case it was), sometimes drugs (which led to some people being fired whenever it became public), lots of sexual harassment complaints (which also led to some surprise firings).
The cult-like part was the CEO fancying himself some Steve Jobs type, doing two-hour long presentations on random topics like his favourite economic ideas, or presenting a treatise against post-modernism. I of course knew which youtube videos he was plagiarising.
It really felt like a Silicon Valley parody when I finally got out.
I find that CEO level bosses (I used to be a teacher so am including heads/principals here) love to pontificate about stuff not related to the job. I've often wondered why. It's sometimes harmless, and clearly,as in your case, sometimes harmful. I do wonder what causes it though.
People who have power over others begin to believe that the positive feedback they get from their employees (simply because they control a person's financial and career success) equates to them being a person of actual interest. They believe the attention means they are smarter, funnier and more charming than they actually are. Tie this to people with narcissistic traits, and you get a strong feedback loop where they never hear dissent, or critique so they fall further into this pattern of behaviour.
You could reverse the statement and say that someone with overly high confidence, an inflated ego and an affinity for preaching is more likely to climb the ladder to C-level. That tracks.
> The cult-like part was the CEO fancying himself some Steve Jobs type, doing two-hour long presentations on random topics like his favourite economic ideas, or presenting a treatise against post-modernism. I of course knew which youtube videos he was plagiarising.
Amazing. So ”Michael Scott from The Office”-type people really exist out there.
To stay on "The Office" universe, that specific CEO was more of a Robert California.
A bit creepy, intimidating, but still able to impress gullible people. He invited employers he thought were "winners" for diners (although the term the company used was "champions"). Instead of being fascinated by Sesame Street he was fascinated by DC Comics, though. I'm actually surprised at how fitting the comparison is.
All without the James Spader charm, of course.
EDIT: In person, however he was a great guy. I just don't think he behaved in a proper way as CEO.
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.
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.
I can only pair effectively if I feel fully comfortable with the person I'm pairing with, and I would not feel uncomfortable disclosing who meets or does not meet that criteria at work.
Software engineers tend to be less comfortable socially so I imagine other people share this perspective.
For people not that familiar with this particular development technique: he means pair programming. When I read "pairing", I think about Bluetooth devices first, which can be an ordeal sometimes, but hardly something that can lead to burnout...
How were the other possible reasons eliminated like aging, depression, and many other factors that also are happening in parallel during the course of 5+ yrs?
That was my thought, if he's been able to maintain pair programming full time for five years, I don't think it was the pair programming that did it in the end.
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.
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 found it to be very intense, but part of that is having to get out of your comfort zone, change your speed of thinking and typing, and a lot of think and communicate before you act. That said, I don't oppose pairing, but only with a set time limit.
I also find this to be the case. Specially on ramp-up the difference is night and day.
I also felt a motivation boost in certain situations.
As with everything, if it makes sense or not, depends on a lot of factors:
Who are you pairing with?
How long? (hours per day/days per week..)
What type of problem are you solving?
All these and more, need to be taken into consideration. Just forcing people to pair is probably not a good idea.
EDIT: Reading a bit more about pairing in general, there seems to be a lot of emphasis on the "one keyboard per pair". I like to keep two keyboards/computers per pair so that I can quickly jump between solo and pairing, to test ideas, investigate etc
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.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design.
If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from.
If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.
That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.
Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back.
Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
"Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.
No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.
Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that.
Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
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.
> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply)
This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.
I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.
I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment:
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.
I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
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".
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.
> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other.
Apparently, pair programming places no value on flow.
> 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.
Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
> Apparently, pair programming places no value on flow.
There are certainly times where flow can be difficult. However I'll offer a few other thoughts.
Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.
I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).
> I just don't see how it's effective
I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:
- I am less easily distracted because I am in flow with someone else
- I am forced to consider my thoughts more carefully because I need to explain them to someone else
- I am confident that someone else can continue this work if I am unavailable
- I enjoy the camaraderie and friendships built with my pairs
- I quickly learn new tools, tricks and ideas from others
- I am able to practice my teaching or coaching skills
- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed
- I take more breaks throughout the day
- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature
- I'm likely to discover something I've missed with a different set of eyes
- I'm likely to take fewer shortcuts, or to be called up on them
- I've become a more effective verbal communicator in the rest of my life
Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
Fundamentally, if two people want to pair, and can meet their obligations as far as delivering work (produce two or more times the work than what's expected of an individual), then feel free. At the end of the day, I don't care how you do your work, any more than I'd dictate which IDE you use. The biggest concern that I'd have in a group with pair programmers is the noise from the constant talking, but most places don't care about having a quiet working environment these days.
However, with pretty much anything like this, just forcing it down everyone's throat is a recipe for disaster. Probably the most confusing thing about the original article was the statements "This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", followed by "It burned me out" and "I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management". Huh?
He realizes the powerful benefits of the technique, but he is an introvert and finds sustained social interaction tiring and stressful for his neurology.
> Apparently, pair programming places no value on flow.
I get flow with and without pairing.
I have ADHD, so for me flow is a spectrum from "smooth, effortless, light" to "destructive hyperfocus". Pairing almost completely prevented hyperfocus in my experience.
> Apparently, pair programming places no value on flow.
For me, the hours zoom by like minutes. The end of the day is suddenly here, and I don't feel like I've worked at all. I was hanging out with a buddy chatting about stuff, and yet there is a pile of completed code in front of us.
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.
Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.
> How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours?
This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time.
> I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too.
> Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work.
The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
> I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing.
I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think.
> Both people are doing these things, except you're both doing them on the same task.
No, one person is doing things, and another is watching and talking while the other person is doing things.
> you get knowledge sharing for free
It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time.
> How much of your programming is actually typing into a text editor?
The vast majority. It doesn't take me 80% of my time to think and plan.
> I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.
I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude.
FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years.
The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.
> The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair.
And yet, my experience has been the exact opposite.
> It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?
> But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?
I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.
> I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked.
And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work.
For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that.
Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."
At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
> Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."
No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development".
> At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
Back at you. I'm not the only one here with strong misgivings and counter examples.
> But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept".
> Also, your car analogy is invalid.
Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.
It's not about a disparity as such. I've had great pairs who I'd say are about equally "good" as me (if one must project to a 1d scale), but who have complementary skills to mine.
Pairing people with the same skill set? Mostly
that’s just a waste.
Strong disagree in my experience. Even with two "evenly matched" developers:
1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL.
2. Each will know tool/workflow tweaks the other doesn't.
3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer.
To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.
I think it can be good for 2 seniors when you need something right now i.e. production bug, or feature that came out of nowhere that needs to ship by EOD. Assembling a strike team of sorts.
>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).
Opt-in for both sides seems like the best option. You should pair program with someone with whom you get along. Joining a place like Pivotal where you have little control over it and have to pair from the outset with someone you don't know a whole lot about just seems like a bad experiment.
I also think it's important to acknowledge individual differences. To give one relevant example, pairing sounds particularly challenging for people on the autism spectrum, which as a group is well-represented among software engineers. Several of the things the author sites as problems (need for sensory breaks, difficulty sustaining social engagement) are real issues for most autistic folks. It's not a coincidence that autistic people talk about "burnout" in much the same way that the author does--a total cognitive shutdown.
I'm not saying the author is autistic, although they might be, I have no idea. But enough people are that designing a work environment that won't work for them is something we want to be very careful about. And even more people aren't autistic but have some overlapping traits--the author might be in this group. That's also where I'd place myself, as someone who's not on the spectrum but has multiple close relatives who are, and sees more than a bit of myself in them, although not enough to be diagnosable. I think I could handle pair programming up to 30 or 40% of the time, but more than that, and I'm pretty sure I'd burn out fast.
I did try it, it works when there is a hard problem to be solved, but for day to day coding no effing way. I can see extroverts who need to communicate a lot enjoying it, but I find they're in the minority with programmers especially the more senior they become. There are instances like mentoring or solving a tough problem, but otherwise I think email and slack and such are good enough communication tools, it doesn't need to be forced.
We do use pair programming to a limited extent: often in the context of a more experienced developer coaching a less experienced developer, or getting a couple of people working together on a particularly tricky problem, so I'm not entirely against it at all. As I said though, this post reads like hell to me.
I've often joked that techniques like pair programming are "software development for extroverts". I certainly didn't get into programming because I'm some sort of out of control social animal, and I was absolutely the stereotypical nerdy kid at school.
I still skew somewhat introverted and need time alone to recharge. What I've found as I've moved through my career is that the more oriented my job is around social interaction, the less I want to be sociable outside of work. Now, as an executive, it's all about the people, and I've dropped to 4 days/week so that I don't turn into a total hermit, shunning all social contact, outside of work. If I don't have a day completely alone at the weekend I really start to struggle. Similarly if my only social interaction comes via work I also struggle. I lose perspective, become tired and disengaged, my judgement and decision-making goes on the wonk: nothing good comes of it. But there's always a balance. I have so much social budget to spend, if you like, and if I spend it all at work I don't have anything left for outside of work (and vice versa) - I always need to find a healthy middle ground.
I am just one data point and I know full well it's different for different people, but I suppose this is one of the issues I find most frustrating about "pairing mandates" (and, yes, I have worked somewhere that had one): enforced pairing doesn't take into account the differences between people. I'm not advocating that we're all special snowflakes but, at the same time, software engineers in general aren't doing basic tasks that can be easily interchanged with different individuals - sometimes not even within their own teams - so it makes little sense to me to force everyone to work in a way, all the time, that a decent number are going to find detrimental.
Let me put it starkly: if I'm working full time as a software engineer and you force me to pair all the time then not only am I going to hate my job fairly quickly, but you are also very literally ruining the rest of my life. I don't want to come home from work completely exhausted with no energy to do anything else and no desire to see friends or family. Not OK. Not OK at all. This is obviously one very effective way to burn people out.
We're all human, and it's helpful for everyone if we can remember that when we're at work.
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.
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'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion.
The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead.
It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion.
As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.
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 want very different things from my rubber ducks and my code reviews.
Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic.
Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices.
Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
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.
Shallow and too late criticism sounds like a problem with how the reviews are handled.
At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved.
I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.
Logically, any review criticism is too late, because the code was already written! Catching the issue before commitment is great, but the proper time for the feedback was during the actual writing. Now the code must be sent back for rewriting, and time has been wasted.
If the code requires such a substantial rewrite after review, that would be indicative of serious communication problems on the team. In 20-odd years of reviewing code, I can't think of many instances where a review led to a substantial rewrite.
I don't know what "substantial" means but, say, in a 3 day long ticket, surely all sorts of issues found in review can easily force another day or so of work.
Anything over half a day would be substantial, but really I'd consider any post code review fix that takes longer than an hour to be a red flag that we're not communicating effectively.
As I alluded to earlier, I've never encountered these sorts of problems in the healthy companies I've worked at (but I HAVE encountered them at unhealthy companies).
Catching problems before things are written is definitely better and that's why it's often a good idea to mention how you intend to approach problems in your daily sync. If someone has concerns, they can bring it up.
But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. In my experience the vast majority of tasks are easily addressed by a single person and most proficient programmers will usually produce perfectly adequate code which doesn't raise any concerns. Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) but saves a lot more time and effort in avoided bugs and issues than the cost of having to rewrite something every now and then.
Additionally, any single submit should be kept to a manageable size so that they're easier to review and issues are caught early. The only times I can remember having insisted someone rewrite something non-trivial have been when they misunderstood some fundamental issue, did not communicate progress as they should have, and did not follow guidelines of solving a single task per submit. That type of behaviour is in itself a pattern which needs to be addressed.
> But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort.
Yes, without a doubt.
> Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task)
Having paired for years, and soloed for years, I have found that the downsides of allocation are overridden by the benefits of pairing, one of which is real-time code review.
I have done some pair programming. At my first job we sometimes did it when some problem proved especially tricky. Typically a tricky bug.
In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either
1) one person tapping out simple code which practically writes itself while the other lazily nods along.
2) One person solving something tricky which happens to be their area of expertise while the other stares blankly. Maybe at that point it would be useful to explain things in detail, but that can make development take much longer and if something like this requires rethinking halfway it can be quite taxing. In that case, I would prefer waiting until it's done and compiling the result as an annotated review. Which can be a great forum for asking questions.
When I've seen it adopted, it was in the context of XP. The red-green-refactor cycle affords a decent flow for pairs, who may switch off between test writing and feature writing. I can see that without the other XP practices, pairing may be awkward.
Another helpful technique to good code reviews is to keep individual PRs small. Once a PR is over a few hundred lines, my eyes start to glaze over and by the end I'm just skimming.
I've had great success with breaking larger changes into smaller PRs that get code-review-merged into an integration branch. Then the integration branch gets merged to your main branch once everything's done and verified.
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.
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.
Yeah, code reviews (like any other process) can be done wrong.
The way to propose a change, in a "good way" (I am assuming here that no one has unilateral capability of merging to master, and things thus have to pass through review), to my mind, involve doing a few things.
<ul>
<li> keep the change small ("small" here is a very fungible quality, but "probably less than n * 1000 lines")
<li> does NOT mix "fix bug" / "add feature" / "refactor" (arguably, there are cases where feature-adding and bug fixing are instrinsically linked, let those through)
<li> has a change description detailing the why of the change (the "what" is the change itself)
</ul>
As a reviewer, your task is not to critique the design (that is why everyone agreed on a design doc up front, no?). It is OK to review the structure of the code, though.
Hopefully, you have a "run this through a linter / style-checker" integrated into your pipeline, so that should be pretty much already done. But, if there are a few things left over, it is OK to point those out.
It is OK to point out that things that should be (but aren't) tested should have tests. If you can spot an edge case that isn't (or doesn't seem to be) tested, ask for that to be tested, also.
People need to be permitted to take the time to do a review.
With these things in place, a review should be pretty quick (at the pace of up to a few lines per second), and most of the time frictionless. But, it does require some discipline, both from the writer and the reviewer.
Personally our industry needs to mature a lot with respect to its ability to critically understand studies before they’re going to be useful. Thus far it seems like the headline version of the first article which purports to analyze a topic is taken as gospel with respect to the topic in question. People still trot out that old article that “finds” that statically typed languages don’t reduce bugs (i.e., 90s era OOP creates enough bugs to offset those precluded by type checkers). If we’re going to depend on formal studies for these hugely multivariate issues we need a lot more rigor before they are more helpful than mere “collective industry experience”.
It's because software is incredibly amorphous. It's incredibly hard to compile meaningful metrics about it, partly because every project is different and used differently. We all know this in the back of our heads, and how incredibly daunting it is to squeeze out quantifiable data from it, so we instead don't tackle it (which is normal behavior for humans) and instead go with stuff that sounds and feels good. Pairing increases your code output Well, two it better than one, so it must be better! TDD prevents bugs? Well, writing the tests first sounds good to me, so it must be better!
Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.
> 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.
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.
Most people are mediocre at nearly everything. The mediocre person who knows their limitations and embraces systems to get the most out of themselves is more valuable than the mediocre person who sees themselves as a rockstar.
> 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.
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.
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.
The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.
In many organisations pairing is encouraged, but not mandated - it means that if developer is stuck with something they ask if someone is available to pair to unblock them. Usually they'll find a person who loves pairing and get things done. In rare cases the PM would tell a developer experienced in the domain, to stop what they are doing and help. That's not too bad provided the interrupted developer gets an extra time added for context switching.
I think in every company, it is encouraged to help someone who is stuck. By "pairing", I mean that a ticket is assigned to a pair, who complete it as a pair. I've never seen a place where some tickets are done by pairs but others, solo. In my experience, if management isn't fully committed to the process of pairing, then they have a hard time understanding how pairing isn't wasting labor.
I see. I tend to avoid organisations that have such culture - I tried this and for me it is too mentally exhausting to constantly be paired with someone.
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 pair and unpair on an ad-hoc basis. I don't care, as long as progress is being made.
Edit - I've never "paired" in the way you suggest in a sibling response (assigning a ticket to 2 developers).
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.
From my perspective, it’s a great way to mentor and facilitate knowledge transfer. It’s also great for working through coding roadblocks. It’s a useful tool, nothing more. Theres no mandate to use it at the office, it’s up to individual developers to use it appropriately and managers to facilitate it.
That's the work that leadership should assisting in -- enabling devs to recognize and move into situations where pairing is beneficial, and giving them the scheduling tools and methods to do it successfully. The best a company should be doing is helping devs to recognize the benefits, and when they are activated for a task, and importantly, when they don't exist for other tasks. It's still such a new area, business wise, that I think it's often done very wrong.
Wait, a squad is a bunch of people close to each other, working on different tasks over the same object. Pair programming is two people close to each other, working on the same task and same object.
Both have completely different problems and advantages. The different (often complementary) tasks make all the difference here.
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 enormous amounts of context in the working memory. This is why developers get into fights that easily.
(Please don't counter with "the humble programmer" and all that; we know, and Dijkstra himself wasn't humble.
)
I agree with this perspective - the closest thing I've seen to this sort of "external enemy" approach in tech is engineers/SREs responding to an outage/critical issue. Good teams will get into a state of flow where people are subdividing work, prioritizing, working as a cohesive unit. In that case, there is a clear objective (get things back up and running) with a clear enemy (that DDoS/database/down payment gateway/datacenter power outage).
I have experienced it both as part of IT emergency response, as well as when cooking with (a very small subset) other people.
As long as everyone is "on the same wavelength" (I am sorry, I cannot quantify that better), it is basically effortless. You need someone to chop onions, and a few minutes later, they're just there. You sense that someone needs a filleting knife (they're just about to place a fish on a cutting board, or something similar that signals "this is the next tool needed") and you're close to it, so you make sure it is there for them (handle first, of course).
It is a very similar feeling to a well-integrated infantry unit making an entry into a presumed-hostile building, minus all the adrenaline.
> 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.
Think you might be pleasantly surprised... concepts like “extreme ownership” (care about everything in your stack), “decentralised command” (push decision making to those doing the work), “cover and move” (help each other) actually translate pretty well.
The book is mostly about dealing with people rather than about engineering process, and I think the people aspects of a coding team and any other high performance team probably have a lot in common.
Sorry about the military reference. I seem to have banged a couple of sore spots.
I'm not a vet (but my parents are planted in Arlington), but I've spent most of my adult life surrounded by them, so I've heard a lot of stories, and they are very practical, pithy applicable stories.
They often spring to mind, when I think about my work.
And we developers may not be thinking in military terms, but the chances are better than even, that the Corner Office is trying on a jacket covered in medals.
>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.
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 has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).
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.
The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached.
The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing.
Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed.
This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.
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.
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 bring up the existing documentation, and have them run through it mostly on their own with me sitting there, asking me whenever they have questions. I watch over their shoulder and nudge them if I see something going awry. They jot down notes that they'll use to update the documentation later. Once they're up and running, they ping me whenever they get stuck, and then jot down notes for the documentation later.
The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level.
The other important part is that they update the documentation.
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'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!
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.
I like to use bringing someone up to speed as a vehicle for improving the documentation. Docs go stale and decay, and require regular maintenance. But without a fresh eye, you become blind to many of the problems the documentation has. Having a new person go through the docs, feel their pain, and fix the problems (with your help) is a golden opportunity to keep the docs fresh and usable, and more importantly codifies knowledge that can otherwise be lost when people leave.
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
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 worked at a place where pair programming was optional but suggested as a good practice. I worked there for 5 years. It was 4 years ago. My team did it and we still talk to each other almost everyday even if we switched jobs.
I think it's a good experience if everyone likes it. I don't think we actually ever did 8 hours straight of pair programming.
Between pauses and meetings it was more 4 hours per day.
I also have a friend a Pivotal and what is described in this article doesn't sound at all like what he usually chats about.
I think that what the author is feeling cannot be result of pair programming alone.
I have to say though that many people dismiss it without even trying like some of the comments on this thread sound like.
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.
307 comments
[ 5.3 ms ] story [ 276 ms ] threadHaving 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.
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, Slack, and reading the news over lunch.
Bring a notebook, and record the work you are doing with your pair. You will need that information for the next-morning's SCRUM.
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.
We didn't always bother switching laptops though and we also worked remotely about half the time (using screenhero at the time, I miss SH).
> And assign someone on the team to be the tea-mug refiller for the day.
I disagree with this. I found frequent breaks to be very important. Pairing is exhausting. "Lets get more tea/coffee" was a good way to have a short break. I think frequent breaks also made using different laptops easier, since its natural to switch drivers after a short break. We didn't have breaks on every switch, of course, but on many we did. The breaks were often only a few minutes, but getting away from the screen even for three minutes really helped.
I occasionally pair with someone, though it's not enforced or even suggested in any way, just a result of discussing a problem for long enough that one of us says "wanna pair on this?".
We use either tmate (a fork of tmux specifically for pairing) or a VSCode plugin, depending on whether what we're pairing on.
I can very much recommend tmate.
What is it with people in our field that this is so commonplace? There are few things worse than a room full of IT people with the windows closed. "It's the smell" as Agent Smith said.
Luckily for my coworkers I am usually remote.
I then learnt several tricks on how to wash my clothes properly, and the problem has gone away completely. Butyric acid stays in your clothes for a long, long time unless you use the right chemicals. I went from horribly smelly guy to no odour overnight.
I now soak all my T-shirts in a bucket with baking soda, rinse them and then put them in another bucket with diluted vinegar, then finally, normal wash. If you have white "pit stains" from deodorant, you want to clean that stuff off. There are special cleaners for that. I do this once every 6 months, and it's enough to keep it all fresh.
Being smelly all the time is a major knock to your self confidence and self image, it's worth the 30 minute hassle twice a year!
If it did what it said on the bottle I'd be fine with it, but it doesn't actually deodorise anything. If you or your clothes are dirty the only way that takes away the smell is to wash, adding another smell on top of it is not a solution.
If they want to make a deodorant they should sell bottles of chlorine gas instead, but then they'd have to answer to the OPCW, never mind the FDA.
Before the pandemic I worked with a lot of lycra biker types who would bike in and then shower at the office, and their wet towels made the whole office reek to high heaven. I mostly don't care about people's actual BO, but I suspect that I'm very sensitive to certain fungal VOCs. They give me migraine-like symptoms. I know some hoarders who haven't taken a shower in years, there's a kind of penile and scrotal aura in the air around them. It's not pleasant, but it's not even on the same scale as mouldy towels and clothes.
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.
Life is waaaaayyy to short for that shit. Work so hard you are in danger of injuring yourself. No thanks.
Which can be solved by taking breaks.
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.
> 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.
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.
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.
I find it funny most people don't realize pair programming is about control. It's like a workplace Stasi. Management expects you to deal with the inevitable conflict resolution, even if that's not your job. Even if your pair shows only for a couple of hours a day and you have to do the work of two people.
“Much harder to spend time on HN” people who like pair programming either like to have power over someone else, or they want to coast and/or be handheld.
People say it's about collaboration... it's more about learning power phrases like “let’s timebox this exploration”, “you have to call the keyboard”, “let’s do plus and deltas”.
I tolerate it because the productivity is so low it helps recovering workaholics.
It's the best secret to dilute accountability and charge outrageous consulting fees.
Also, is there a pair programming equivalent of the Scrum Master? That would be the chief slack position.
It certainly is exhausting. It certainly produces better code. If you pair and rotate, then after a number cycles, everyone in the team knows the codebase.
There is something a bit weird about XP. It looks as if coders are being given control, and they are; but they manage themselves even more sternly than their management would have. That is, coders seem to demand more of themselves than even aggressive managers.
Everyone knowing the codebase is also a way for developers to shoot themselves in the foot; when everyone knows your job, it becomes easier for you to be replaced.
I'm not a master programmer - at best, I was a journeyman. I learned a lot from the people I paired with, about half of whom were better than me. I only paired with two guys that I found really difficult; one was a good programmer, but had quite severe asperger's. The other was a reckless, entitled idiot, and pairing with him amounted to trying to stop him writing any code.
I'm not familiar with those "power-phrases". And I never encountered power games. I guess we all had enough confidence in ourselves and our colleagues that we didn't feel we had to prove anything. We respected one-another. Well, I certainly respected (most of) the other team members.
In a disfunctional team, I guess pairing can only make things worse.
Regarding diluted accountability: I found the oppposite. At the morning SCRUM, you have to give an account of what you did yesterday. You can't make it up, because your pair is at the SCRUM too. And the evidence is in the commit log.
And I didn't find that productivity was low. I'd say that functionality was delivered at about 75% the velocity of solo work, but the code we delivered was much better quality, so maintenance and bug-fixing was massively reduced.
I was working with a team of rather good people; I imagine pairing might be a lot more tedious and unproductive if the majority of the team are dim, incompetent, socially maladapted, or psychopathic. But then the same applies to solo coding.
I don't know what a "Pivot" is.
I sense that you might be saying those phrases can be used to manipulate the other half of the pair. For the first one, I can speculate: The pair disagrees how to approach some problem, then one of the two suggests to “timebox an exploration” into their favorite approach, and then after spending an hour on it (or whatever), the code is already there and nobody wants to delete it again.
But what do the other two phrases even mean, and how would they be used to manipulate?
I think this is one of those things that is going to work for some and not work for others.
I quit very quickly after being subcontracted into Pivotal. I need quiet focussed periods of inner monologue to turn over problems. I can't talk and think.
Other people think by talking. I suppose artificially limiting the types of people who work for you is a choice of some kind
This can be true of any demanding job.
Pairing is like running or cycling together. One person will be faster or have more endurance than the other. The slower one must set the pace or they will get exhausted quickly. For sustainable daily pairing, I would expect the team to quickly develop a hierarchy of speeds, with the lower speed person in every pair controlling the console.
It's true that the slower person should set the pace; unfortunately that doesn't always happen. I found that some of my pairs were so much faster than me, that they had to spend quite a lot of time explaining what they were doing - I was slowing them down.
But with rotation, it won't be more than a couple of days before you're paired with someone more closely-matched to your abilities.
In my experience, with daily pairing, both workers felt completely drained of energy after 4 hours (including pauses).
Pairing a couple hours a day, or a couple times a week is alright, and very productive. Doing it 5 days a week is borderline inhumane.
We mortals, are likely more suitable for moderate programming, with infrequent informal pairing when necessary.
Having the same supper feels more of a way to avoid stress, to avoid making multiple decisions daily, to have some grounding in your life, to have less risk. Similar to Steve Jobs wearing the same uniform everyday to work. [1]
As said in other post in this thread, by Cthulhu_, part of the appeal of pairing is "getting out of your comfort zone". I don't think this guy wants to be out of his comfort zone for 8 hours a day.
If he were a coder, maybe "stability" would be working solo. Maybe he would have liked 8hrs/day pairing. Maybe he'd prefer start his coding around 6:00 and going home after lunch. No way of knowing.
[1] https://www.forbes.com/sites/jacquelynsmith/2012/10/05/steve...
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.
Why couldn't you talk through it out loud?
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.
If your employer expects you to be productive 8 hours a day I’d look for something else
There's the expectation from non-technical managers that time away from the keyboard is "wasted" - that coding is a matter of pushing the buttons constantly, and that code is of a consistent quality, so more of it is better.
There's also the bullshit long-hours work culture where leaving work before the boss does is somehow unacceptable.
The best approach I've found is to explain that the codebase is an asset that can be damaged. And the code itself is a liability - it must be maintained in the face of changing requirements and technology. "More code" is worse, not better, for the company. So having tired developers write bad code is both damaging our asset and introducing more liabilities. We need our devs rested and on their game to avoid that. We need them thinking deeply about the code they're going to write. And that thought doesn't have to occur at the keyboard. Good devs think about their code while going about the rest of their lives.
It's better if a tired dev goes home to rest rather than continuing working on the code, because they'll just end up damaging it if they work on it tired.
It's better for a dev to go for a walk to think deeply about what they're doing rather than write code that they're not sure about.
We don't want devs working on the codebase after ~8 hours, because they probably haven't thought enough about what they're writing.
It can work. Depends on company culture.
There's also so much bullshit in dev culture itself about "marathon hacking sprints". I bought into this myself, did a 32-hour sprint to meet a deadline. It was a complete mess. I would have been so much better off getting some sleep, a decent meal, and going for a walk in the middle. I think most devs go through this lesson at some point.
A nitpick: the better analogy is that code is an inventory asset. It can decay or rot, it costs money to acquire and money to maintain.
But it is not a debt owed to someone else, as a liability is.
https://proxy.c2.com/cgi/wiki?SoftwareAsLiability
What the code does is an asset. The code itself is a liability.
We have "tech debt" that isn't actually owed to anybody yet must be paid.
But it doesn't drive home the message that more code doesn't mean more asset. Having a developer write more code doesn't automatically create more value. The value is in what the code does, not the code itself. And a developer can actively harm the codebase by working on it. You can pay someone to improve it, and the end result is a decrease in value, not an increase. I'm not sure there are other asset classes that behave the same way. I could be wrong.
It might be possible, but it definitely would not be acceptable!
Red flag for all kinds of weirdness if you're made to take on a company-based identity.
[0] https://obie.ai/blog/wp-content/uploads/2020/08/noogler.jpeg
Pivotal definitely had an incredibly strong cultural field strength. That much it shares with cults. Personally, I loved it, like anyone who finds a fit in such a place.
You have no idea. I. Have. Seen. Things.
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.
It's amazing how workplaces can get in these kind of darkly comic places
There was literal chest beating and shouting motivational stuff during sales meetings, an incredibly amount of beer (which isn't necessary an issue, but in this case it was), sometimes drugs (which led to some people being fired whenever it became public), lots of sexual harassment complaints (which also led to some surprise firings).
The cult-like part was the CEO fancying himself some Steve Jobs type, doing two-hour long presentations on random topics like his favourite economic ideas, or presenting a treatise against post-modernism. I of course knew which youtube videos he was plagiarising.
It really felt like a Silicon Valley parody when I finally got out.
I find that CEO level bosses (I used to be a teacher so am including heads/principals here) love to pontificate about stuff not related to the job. I've often wondered why. It's sometimes harmless, and clearly,as in your case, sometimes harmful. I do wonder what causes it though.
Amazing. So ”Michael Scott from The Office”-type people really exist out there.
A bit creepy, intimidating, but still able to impress gullible people. He invited employers he thought were "winners" for diners (although the term the company used was "champions"). Instead of being fascinated by Sesame Street he was fascinated by DC Comics, though. I'm actually surprised at how fitting the comparison is.
All without the James Spader charm, of course.
EDIT: In person, however he was a great guy. I just don't think he behaved in a proper way as CEO.
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?
Also it was only really enforced during Sprint Retrospectives.
In the end it's all just part of a much bigger issue within the whole company.
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
> 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/
https://sonnet.io/posts/snakes/
Software engineers tend to be less comfortable socially so I imagine other people share this perspective.
How repeatable is this pattern?
How were the other possible reasons eliminated like aging, depression, and many other factors that also are happening in parallel during the course of 5+ yrs?
Correlation does not mean causation.
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.
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 also felt a motivation boost in certain situations.
As with everything, if it makes sense or not, depends on a lot of factors:
All these and more, need to be taken into consideration. Just forcing people to pair is probably not a good idea.EDIT: Reading a bit more about pairing in general, there seems to be a lot of emphasis on the "one keyboard per pair". I like to keep two keyboards/computers per pair so that I can quickly jump between solo and pairing, to test ideas, investigate etc
* 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.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from.
If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.
Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
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.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.
I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.
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.
Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
> 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.
Apparently, pair programming places no value on flow.
> 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.
Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
There are certainly times where flow can be difficult. However I'll offer a few other thoughts.
Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.
I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).
> I just don't see how it's effective
I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:
- I am less easily distracted because I am in flow with someone else
- I am forced to consider my thoughts more carefully because I need to explain them to someone else
- I am confident that someone else can continue this work if I am unavailable
- I enjoy the camaraderie and friendships built with my pairs
- I quickly learn new tools, tricks and ideas from others
- I am able to practice my teaching or coaching skills
- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed
- I take more breaks throughout the day
- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature
- I'm likely to discover something I've missed with a different set of eyes
- I'm likely to take fewer shortcuts, or to be called up on them
- I've become a more effective verbal communicator in the rest of my life
Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
However, with pretty much anything like this, just forcing it down everyone's throat is a recipe for disaster. Probably the most confusing thing about the original article was the statements "This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", followed by "It burned me out" and "I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management". Huh?
I get flow with and without pairing.
I have ADHD, so for me flow is a spectrum from "smooth, effortless, light" to "destructive hyperfocus". Pairing almost completely prevented hyperfocus in my experience.
For me, the hours zoom by like minutes. The end of the day is suddenly here, and I don't feel like I've worked at all. I was hanging out with a buddy chatting about stuff, and yet there is a pile of completed code in front of us.
https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...
This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time.
> I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too.
> Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work.
The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think.
> Both people are doing these things, except you're both doing them on the same task.
No, one person is doing things, and another is watching and talking while the other person is doing things.
> you get knowledge sharing for free
It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time.
> How much of your programming is actually typing into a text editor?
The vast majority. It doesn't take me 80% of my time to think and plan.
> I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.
FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
You're free to whatever interpretation you wish. I'm glad it worked out for them (and you).
> It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
I hope you can look back at that statement and see how ludicrous it sounds.
The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.
And yet, my experience has been the exact opposite.
> It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?
I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.
And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work.
For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that.
Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."
At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development".
> At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
Back at you. I'm not the only one here with strong misgivings and counter examples.
> But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept".
> Also, your car analogy is invalid.
Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.
1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL.
2. Each will know tool/workflow tweaks the other doesn't.
3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer.
To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.
Opt-in for both sides seems like the best option. You should pair program with someone with whom you get along. Joining a place like Pivotal where you have little control over it and have to pair from the outset with someone you don't know a whole lot about just seems like a bad experiment.
I'm not saying the author is autistic, although they might be, I have no idea. But enough people are that designing a work environment that won't work for them is something we want to be very careful about. And even more people aren't autistic but have some overlapping traits--the author might be in this group. That's also where I'd place myself, as someone who's not on the spectrum but has multiple close relatives who are, and sees more than a bit of myself in them, although not enough to be diagnosable. I think I could handle pair programming up to 30 or 40% of the time, but more than that, and I'm pretty sure I'd burn out fast.
We do use pair programming to a limited extent: often in the context of a more experienced developer coaching a less experienced developer, or getting a couple of people working together on a particularly tricky problem, so I'm not entirely against it at all. As I said though, this post reads like hell to me.
I've often joked that techniques like pair programming are "software development for extroverts". I certainly didn't get into programming because I'm some sort of out of control social animal, and I was absolutely the stereotypical nerdy kid at school.
I still skew somewhat introverted and need time alone to recharge. What I've found as I've moved through my career is that the more oriented my job is around social interaction, the less I want to be sociable outside of work. Now, as an executive, it's all about the people, and I've dropped to 4 days/week so that I don't turn into a total hermit, shunning all social contact, outside of work. If I don't have a day completely alone at the weekend I really start to struggle. Similarly if my only social interaction comes via work I also struggle. I lose perspective, become tired and disengaged, my judgement and decision-making goes on the wonk: nothing good comes of it. But there's always a balance. I have so much social budget to spend, if you like, and if I spend it all at work I don't have anything left for outside of work (and vice versa) - I always need to find a healthy middle ground.
I am just one data point and I know full well it's different for different people, but I suppose this is one of the issues I find most frustrating about "pairing mandates" (and, yes, I have worked somewhere that had one): enforced pairing doesn't take into account the differences between people. I'm not advocating that we're all special snowflakes but, at the same time, software engineers in general aren't doing basic tasks that can be easily interchanged with different individuals - sometimes not even within their own teams - so it makes little sense to me to force everyone to work in a way, all the time, that a decent number are going to find detrimental.
Let me put it starkly: if I'm working full time as a software engineer and you force me to pair all the time then not only am I going to hate my job fairly quickly, but you are also very literally ruining the rest of my life. I don't want to come home from work completely exhausted with no energy to do anything else and no desire to see friends or family. Not OK. Not OK at all. This is obviously one very effective way to burn people out.
We're all human, and it's helpful for everyone if we can remember that when we're at work.
Automatic material for two HBO seasons.
It seems like it would only be good on tasks where having your partial work continuously reviewed is very valuable.
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.
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.
The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead.
It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion.
As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.
Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic.
Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices.
Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved.
I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.
As I alluded to earlier, I've never encountered these sorts of problems in the healthy companies I've worked at (but I HAVE encountered them at unhealthy companies).
But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. In my experience the vast majority of tasks are easily addressed by a single person and most proficient programmers will usually produce perfectly adequate code which doesn't raise any concerns. Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) but saves a lot more time and effort in avoided bugs and issues than the cost of having to rewrite something every now and then.
Additionally, any single submit should be kept to a manageable size so that they're easier to review and issues are caught early. The only times I can remember having insisted someone rewrite something non-trivial have been when they misunderstood some fundamental issue, did not communicate progress as they should have, and did not follow guidelines of solving a single task per submit. That type of behaviour is in itself a pattern which needs to be addressed.
Yes, without a doubt.
> Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task)
Having paired for years, and soloed for years, I have found that the downsides of allocation are overridden by the benefits of pairing, one of which is real-time code review.
In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either
1) one person tapping out simple code which practically writes itself while the other lazily nods along.
2) One person solving something tricky which happens to be their area of expertise while the other stares blankly. Maybe at that point it would be useful to explain things in detail, but that can make development take much longer and if something like this requires rethinking halfway it can be quite taxing. In that case, I would prefer waiting until it's done and compiling the result as an annotated review. Which can be a great forum for asking questions.
I've had great success with breaking larger changes into smaller PRs that get code-review-merged into an integration branch. Then the integration branch gets merged to your main branch once everything's done and verified.
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.
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.
The way to propose a change, in a "good way" (I am assuming here that no one has unilateral capability of merging to master, and things thus have to pass through review), to my mind, involve doing a few things.
<ul> <li> keep the change small ("small" here is a very fungible quality, but "probably less than n * 1000 lines") <li> does NOT mix "fix bug" / "add feature" / "refactor" (arguably, there are cases where feature-adding and bug fixing are instrinsically linked, let those through) <li> has a change description detailing the why of the change (the "what" is the change itself) </ul>
As a reviewer, your task is not to critique the design (that is why everyone agreed on a design doc up front, no?). It is OK to review the structure of the code, though.
Hopefully, you have a "run this through a linter / style-checker" integrated into your pipeline, so that should be pretty much already done. But, if there are a few things left over, it is OK to point those out.
It is OK to point out that things that should be (but aren't) tested should have tests. If you can spot an edge case that isn't (or doesn't seem to be) tested, ask for that to be tested, also.
People need to be permitted to take the time to do a review.
With these things in place, a review should be pretty quick (at the pace of up to a few lines per second), and most of the time frictionless. But, it does require some discipline, both from the writer and the reviewer.
Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.
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.
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.
This is a feature, not a bug!
Most people are mediocre at nearly everything. The mediocre person who knows their limitations and embraces systems to get the most out of themselves is more valuable than the mediocre person who sees themselves as a rockstar.
"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.
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.
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 pair and unpair on an ad-hoc basis. I don't care, as long as progress is being made.
Edit - I've never "paired" in the way you suggest in a sibling response (assigning a ticket to 2 developers).
Is collaboration / pairing part of employee evaluation in any way?
Both have completely different problems and advantages. The different (often complementary) tasks make all the difference here.
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 enormous amounts of context in the working memory. This is why developers get into fights that easily.
(Please don't counter with "the humble programmer" and all that; we know, and Dijkstra himself wasn't humble. )
As long as everyone is "on the same wavelength" (I am sorry, I cannot quantify that better), it is basically effortless. You need someone to chop onions, and a few minutes later, they're just there. You sense that someone needs a filleting knife (they're just about to place a fish on a cutting board, or something similar that signals "this is the next tool needed") and you're close to it, so you make sure it is there for them (handle first, of course).
It is a very similar feeling to a well-integrated infantry unit making an entry into a presumed-hostile building, minus all the adrenaline.
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.
The book is mostly about dealing with people rather than about engineering process, and I think the people aspects of a coding team and any other high performance team probably have a lot in common.
I'm not a vet (but my parents are planted in Arlington), but I've spent most of my adult life surrounded by them, so I've heard a lot of stories, and they are very practical, pithy applicable stories.
They often spring to mind, when I think about my work.
And we developers may not be thinking in military terms, but the chances are better than even, that the Corner Office is trying on a jacket covered in medals.
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!
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.
If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).
I have yet to try it out though.
The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing.
Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed.
This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.
"Bloing!" -- "Oh look, I think I need to read that email now." -- "OK, I'll toodle over to my own desk and see if I've got any. See you in five."
A computer isn't a hip.
You don’t. That’s what breaks are for (assuming personal e-mail).
> What if there's documentation that needs to be read?
- Define an objective together (e.g. „We‘d like to understand how the HTML progress element works“)
- Optionally, agree an a timeout
- Split (both reading at their own pace, on their own device)
- Join and discuss results
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.
The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level.
The other important part is that they update the documentation.
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.
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!
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.
At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
I also have a friend a Pivotal and what is described in this article doesn't sound at all like what he usually chats about.
I think that what the author is feeling cannot be result of pair programming alone. I have to say though that many people dismiss it without even trying like some of the comments on this thread sound like.
* 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