The mortifying ordeal of pairing all day(simplermachines.com)
simplermachines.com
The mortifying ordeal of pairing all day
https://www.simplermachines.com/the-mortifying-ordeal-of-pairing-all-day/
306 comments
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.
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.
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.
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.
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.
...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging )
I 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.
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 do this. It works. I have a stuffed parrot though. And everyone thinks I’m nuts but I don’t care :)
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.
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.
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'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.
Yes, I also have great experiences with this type of approach.
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.
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. 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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
"Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.
...and then complain that there is a "shortage" of developers.
I think a developer presenting themselves as unqualified for the job, via being an asshole in a job that requires good communication skills and teamwork, you have a pass to say you have not gotten a qualified candidate yet.
> it's only attractive to very mediocre engineers
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.
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.
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 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.
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. )
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.
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.
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.
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.
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.
Both have completely different problems and advantages. The different (often complementary) tasks make all the difference here.
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.
Pairing is a decision made between two devs, not as a team or company, imo.
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.
I've never seen or even heard of a place where pairing is optional. I've only ever seen it compulsory or forbidden.
Pairing is optional at my employer.
As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers.
I have also managed people who just like to work together and they're free to 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).
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).
>Pairing is optional at my employer.
Is collaboration / pairing part of employee evaluation in any way?
Is collaboration / pairing part of employee evaluation in any way?
Not directly. If somebody actively avoided paired work, I'd probably ask them about it during a regularly scheduled 1-on-1. And if somebody was doing a spectacular job mentoring/pairing/etc I'd definitely mention it.
That seems pretty reasonable. I'd hate to work at a place that "didn't enforce" something, but had it turn into a 15 pieces of flair type situation.
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.
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.
That's definitely not ideal. Ideally pairing is "authorized" not mandated.
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.
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!
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.
Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.
The 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.
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.
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).
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).
They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/
I have yet to try it out though.
I have yet to try it out though.
I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.
> how do you check your e-mail?
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
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
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.
Well, no, in our case it literally did mean we were "joined at the hip" - we shared one computer.
"Bloing!" -- "Oh look, an email. Never mind, I'll read that later."
"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.
"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.
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.
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.
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.
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!
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.
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)!
That's very interesting, i never thought about pairing as a tool that help people with ADHD stay focused.
At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
It’s funny you mention ThoughtWorks, I’m happily (enough) employed right now. But I’ve thought about applying for years. I appreciate the offer :)
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.
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 sounds awful.
It's amazing how workplaces can get in these kind of darkly comic places
It's amazing how workplaces can get in these kind of darkly comic places
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.
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.
> 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.
Amazing. So ”Michael Scott from The Office”-type people really exist out there.
Oh yes. I can't even watch The Office because it's too real.
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.
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.
I'm glad you 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.
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.
This is part of the reason why I left management. I really do feel that the positive feedback loop was getting to my head.
A profound terror of their own personal insignificance and mortality?
True! I think deep down we all want to be influential. They're just trying to cheat their way into it.
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.
> there was a Fight-club-style "rule"
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?
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?
Sorry if I didn't make it clear: the junior developer did take advantage of it when CEO asked.
Also it was only really enforced during Sprint Retrospectives.
Also it was only really enforced during Sprint Retrospectives.
Not raising obvious problems with the process sounds just as dysfunctional as the pairing idea that created the situation in the first place.
> 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".
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
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
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.
[1] https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
> 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/
that sounds exhausting.. holy fk, i could pair maybe half of the day, and at most like 1-2 weeks at a time
I’ve had incredible experiences pairing.
There were whiteboards, snacks, rating each other’s themes, and jokes.
What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code.
We’d then break away and work at our own speed and in our own style using the common foundation.
Come together to integrate and discuss.
Pairing is also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.
It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.
A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.
There were whiteboards, snacks, rating each other’s themes, and jokes.
What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code.
We’d then break away and work at our own speed and in our own style using the common foundation.
Come together to integrate and discuss.
Pairing is also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.
It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.
A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.
I like pairing for debugging a problem or discussing a design solution. You get stuck, bring someone in and discuss it, let them look at the code, point something out that sets your brain on the right track, or a solution pops in your head from something random they said or from the process of you explaining thing. Many, many issues have been solved that way.
But I hate it in all other circumstances, especially when it comes to actual coding.
But I hate it in all other circumstances, especially when it comes to actual coding.
This works and I think is the natural way of things for human beings to bounce things off one another but for it to be a constant; no way!
Pairing is also, bar none, the best way I've seen to onboard a new hire. There is no better way to learn a codebase than to work closely with someone who knows that codebase, on a real-world, production problem.
The best way I found to onboard was what I called "half day onboarding". Half the day the mentor can help, the other half the new person has to be self sufficient. Otherwise people start using their mentor as a crutch. This is the way I brought on new people as team manager.
Yeah. I almost want to say it's the only realistic way to onboard.
Depending on the codebase, I feel it's literally 10-50x more productive.
Depending on the codebase, I feel it's literally 10-50x more productive.
I know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
I actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would discuss with him like 4-5 times a day sometimes.
It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I never tried it, so I don't know.
It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I never tried it, so I don't know.
I feel like if I would've been sitting with him
I would have wasted a lot of his time
What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense.
Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it.
I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided.
Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.
To be fair, in the cases I'm thinking of it's more just chucking a new guy into the mess without direction.
I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
I assume you are an extroverted person? Talking that much with another human being outside of someone I care dearly about just does not work for me, it just makes me anxious af. I'm glad it works for you and may you always another fellow extrovert to work. I left a job because they demanded pair programming as the new company paradigm. And yeah I gave it a shot for 3 months, and the other person was about as easy as anyone I could imagine anyone to be, but honestly I got tired of staring at his stupid face (although he was actually quite smart and capable, I just didn't want to see/communicate with him 8-10 hours a day)
Not at all. Excessive pairing makes me tired. And I, as many, loose my ability to type when someone is watching.
All in all, the actual pairing can be limited to 1h every few days. Done well it’s enough.
Demanding a work mode is stupid. Be it forced TDD, forced pairing, or forced welding when all you need is some glue.
All in all, the actual pairing can be limited to 1h every few days. Done well it’s enough.
Demanding a work mode is stupid. Be it forced TDD, forced pairing, or forced welding when all you need is some glue.
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 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:
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
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?
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.
It's good for a number of things:
* 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.
* 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.
> * 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.
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.
> Having multiple perspectives on design.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
Why not?
For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.
1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.
1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.
Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
> 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.
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 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.
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 find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not.
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.
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.
I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.
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. 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?
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 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.
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.
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.
All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.
And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
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.
> 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.
> 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!
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?
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?
> 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.
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.
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.
I suggest you try it for a week. Code as conversation.
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.
Excellent points. Here are some good ideas for getting started.
https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...
https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...
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.
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.
>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.
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'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.
I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option to reduce costs is to have the customer supply half of the pair team, so I did this for a few half days one one project.
This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.
My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:
1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.
2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.
3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.
Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.
There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.
This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.
My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:
1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.
2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.
3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.
Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.
There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.
In answer to a sister comment about a location where pairing was only for the underlings (https://news.ycombinator.com/item?id=27103743) I will say that one other thing Menlo does to show they are serious is that the do pairing in other places too. Even their "High Tech Anthropologists" (people who get the specs from the customers), and the project managers work in pairs. I think that helps the culture around pairing significantly.
"We were Pivots, and one of the things that made us Pivots was that we paired."
Red flag for all kinds of weirdness if you're made to take on a company-based identity.
Red flag for all kinds of weirdness if you're made to take on a company-based identity.
The company you work for is not a personality.
Pivot, as in ... part of a machine I guess :-)
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".
[0] https://obie.ai/blog/wp-content/uploads/2020/08/noogler.jpeg
[0] https://obie.ai/blog/wp-content/uploads/2020/08/noogler.jpeg
Sadly very common in Silicon Valley culture. And this is far from the most cult-like thing about Pivotal.
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.
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.
>red flags for all kinds of weirdness
You have no idea. I. Have. Seen. Things.
You have no idea. I. Have. Seen. Things.
A few years ago, I worked on a project for about 11 months with one other guy and we paired almost all the time. Yes, it was mentally exhausting, yes we had some natural resistance to it at first. But damn was it effective, in producing higher quality code (two eyes on the code, two people to work out every problem or bug, always having someone to ping ideas off), in terms of knowledge sharing (we both understood every single bit of the code) and in terms of shipping on time. It was a complex project (reliably delivering large libraries of content to fleets of airplanes over satellite internet) and we delivered it from start to finish in under a year.
Some mornings I would wake up and really not want to pair, but I'd do it anyway because its what we agreed we'd do, and after an hour or so, I got over it and we were super productive. Sometimes I miss it, especially since I'm mostly working on my own these days.
I don't work there anymore, but last I checked with former colleagues the code was still ticking along in production with no issues.
When pairing, its important to take regular breaks and also to not overdo it (don't work overtime). It IS mentally draining. Most people are also naturally resistant to the idea and I don't think it can work unless all involved people buy into it. But I found it was the most effective way I've ever worked and also quite rewarding.
Some mornings I would wake up and really not want to pair, but I'd do it anyway because its what we agreed we'd do, and after an hour or so, I got over it and we were super productive. Sometimes I miss it, especially since I'm mostly working on my own these days.
I don't work there anymore, but last I checked with former colleagues the code was still ticking along in production with no issues.
When pairing, its important to take regular breaks and also to not overdo it (don't work overtime). It IS mentally draining. Most people are also naturally resistant to the idea and I don't think it can work unless all involved people buy into it. But I found it was the most effective way I've ever worked and also quite rewarding.
This is an introvert's nightmare.
The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns.
Pairing is incredibly useful and valuable, but doing it all day would be hell.
If someone told me that they wanted me to pair for the majority of my day, or even the majority of code I wanted to write, the first thing I would pair on would be a letter of resignation.
The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns.
Pairing is incredibly useful and valuable, but doing it all day would be hell.
If someone told me that they wanted me to pair for the majority of my day, or even the majority of code I wanted to write, the first thing I would pair on would be a letter of resignation.
Reading about them only having workstations for every other people, I would have turned on my heels and walked out the first day!
As an introvert myself, strong disagree. I (and introverts in general, to my knowledge) don’t have any trouble interacting with people in small group settings when those interactions are focused on ideas. The problems come with large group settings and small talk. Pairing is in the first category, not the second.
Your description of introversion fits with mine, but pairing with someone _all day_ would completely drain me of any energy.
As someone who worked in an all pairing shop for two years (run by a bunch of former Pivots), I can confirm it’s pretty draining, though my experience wasn’t nearly as bad.
I actually liked pairing a lot of the time, and still think it’s an excellent way to onboard into a new code base, even in a non pairing shop (I even miss it sometimes!). For me, the main drawback after a while was that I felt like I was less efficient when pairing on stuff I knew how to do, and my personal growth as an engineer was stunted because I could always lean on a more experienced pair. Since that was my first eng gig, my second job had quite a steep learning curve as I had to figure out how to debug and navigate on my own, without talking through it out loud.
I 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.
> 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?
Why couldn't you talk 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.
Sounds funny if you talk aloud while no one else is there.
There’s actually a term for this: https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
I still have a blue rubber duck with "integer overflow" written on it. Got it many years ago but interestingly enough I never used it.
How the heck can people work like that for 8 hours? I start to get very worn out at 2 hours of conversation.
I've paired on a couple projects and miss it. The exhaustion is very real but pairing really works when you take breaks.
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.
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.
> 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.
Life is waaaaayyy to short for that shit. Work so hard you are in danger of injuring yourself. No thanks.
My limited experience with pairing has been positive. The negative is you can easily get caught up in the pace.
Which can be solved by taking breaks.
Which can be solved by taking breaks.
Yep feels forced like hell, no breathing room. Isn't it enough to be a team of two without holding hands all the time?
It feels inhumane to me. Maybe for a little bit would be ok though.
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.
Work patterns, emails, special requests from team members, bladder, time for collecting thoughts, etc.
But how often do you do long conversations? I also find it exhausting, but like almost everything: the more you do it the easier it gets.
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.
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.
Yep. 6 hours of pairing feels more like 12 hours of solo coding.
Isn't that what I stated here?
> 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 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.
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.
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 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.
Can you share this research data?
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.
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.
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.
Microsoft tried the 4-day work week, for example: https://www.npr.org/2019/11/04/776163853/microsoft-japan-say...
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.
Shorter days makes much more sense to me than shorter weeks. Wherever I've worked those last two hours of the day are always a waste.
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
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.
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.
> And the code itself is a liability - it must be maintained in the face of changing requirements and technology.
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.
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.
I was quoting other, smarter, people.
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.
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.
I disagree with the other, smarter people, is my refined 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.
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!
It might be possible, but it definitely would not be acceptable!
When I started my first job programming job out of university, I spent a lot of time pairing with one of my teammates (online) at the beginning. Not necessarily because it was enforced, but I think we figured it would just be a good way to learn. This went on for a few months, over time I'd take shots at doing tasks for myself, some with more or less success.
Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.
Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.
Project management is fundamentally about managing human psychology. This is a horrifying prospect, because we do not truly understand human psychology at a mechanistic level, much less to the point where it can be applied to the individual.
Therefore, we instead seek refuge in processes and rituals that are, for practical reasons, not validated by experiment. One can hide almost any issue in a forest of obtuseness. If something doesn't work out, one can always blame it on some failure in adherence to the dogma.
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 like pair programming.
Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc.
I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing.
Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.
--
As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.
It is just a different way to achieving the outcome.
If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.
But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.
So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.
I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.
--
I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.
Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc.
I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing.
Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.
--
As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.
It is just a different way to achieving the outcome.
If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.
But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.
So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.
I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.
--
I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.
This means that if I'm working alone I can do the same amount of work with 2 pomodoro hours (absolute focus for 50 minutes x2).
Pomodoro does not generally improve focus, it just helps prevent procrastination.
Pair programming is another way to do the same -- since you have agreed with the other person to start at agreed time and work for specified number of hours it is much more difficult for you to suddenly stray to reading Hacker News.
It does not necessarily mean your quality of focus will be better, it just means there will be minimum quantity of it.
Pair programming is another way to do the same -- since you have agreed with the other person to start at agreed time and work for specified number of hours it is much more difficult for you to suddenly stray to reading Hacker News.
It does not necessarily mean your quality of focus will be better, it just means there will be minimum quantity of it.
Is it just me or is it trivially easy to get all the benefits the author describes without the downsides? Maybe just do it fewer hours for fewer days. Build in enough time for full recuperation. I'd say half as many workstations as people is definitely asking for trouble.
There's also the other extreme, Mob Programming, where you get everyone in a room together with one projected screen.
The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.
https://mobprogramming.org/
The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.
https://mobprogramming.org/
I have used this at several work places for particularly thorny issues and architectural changes that require group buy in.
It's powerful, but it's also very expensive, especially if you have several opinionated devs on the team.
It's powerful, but it's also very expensive, especially if you have several opinionated devs on the team.
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.
edit: formatting
* 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
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 could deal with this for maybe a week. 6 years is just mind-bending. Incredible endurance/tolerance.
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.
>people who refused to use deodorant
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.
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.
There is no deodorant that can suppress my BO, I just end up smelling like BO with a hint of deodorant.
Luckily for my coworkers I am usually remote.
Luckily for my coworkers I am usually remote.
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 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.
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.
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.
Agree with many sentiments described here. I was one of the early pioneers in this area, starting with XP in 1998. At the time, it was cool because it was counter culture, rather than cargo culture. I remember having to get approval from the president of our 500 person company to come in on our own time on a Saturday to take down a cubicle wall, so that we could have a larger collective space.
Some pairings were a delight to participate in; others more strained. But when it worked, it was super cool. It was like that dribble attack on the goal where you just read each other's minds.
One thing we learned early on though, was that any real debugging didn't work well this way. We even codified it as "debugging break" where we would split apart and sort of mumble aloud the different things we were seeing as we pursued our various intuitions and hunches.
Now days, I rarely pair anymore. The skill gap in my current team is pretty varied. The sense of self is strong, which generally goes against the "us before I" gestalt of pair programming. I do find when I need to answer questions or demonstrate, I tend to put myself in the passenger chair and turn it into a pairing experience for the other.
Some pairings were a delight to participate in; others more strained. But when it worked, it was super cool. It was like that dribble attack on the goal where you just read each other's minds.
One thing we learned early on though, was that any real debugging didn't work well this way. We even codified it as "debugging break" where we would split apart and sort of mumble aloud the different things we were seeing as we pursued our various intuitions and hunches.
Now days, I rarely pair anymore. The skill gap in my current team is pretty varied. The sense of self is strong, which generally goes against the "us before I" gestalt of pair programming. I do find when I need to answer questions or demonstrate, I tend to put myself in the passenger chair and turn it into a pairing experience for the other.
> 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.
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.
Not clear why this was downvoted.
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.
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.
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.
https://news.ycombinator.com/item?id=27082522 - this guy is cut out for Extreme Programming. If something is good, why not have it all the time, right?
We mortals, are likely more suitable for moderate programming, with infrequent informal pairing when necessary.
We mortals, are likely more suitable for moderate programming, with infrequent informal pairing when necessary.
I don't think it's an apt comparison.
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...
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 had so many negative experience pair programming that I started to find ways to avoid it.
There were the pairs the insisted on using vim[1]. There were the pairs that hogged the keyboard. I'm sure there were other things that frustrated me about it (it's been a long time since this was an every day thing now). In the end though, I opted out of pairing, first by taking a devops role at the same company that didn't require it, and later by not applying to any company that had that as a requirement.
To be clear, I'm not against pairing occasionally, but overall I prefer to be alone with my thoughts while programming -- not having to negotiate every little thing with a new pair.
If that doesn't suit the company, then so be it.
[1] I have nothing against vim, and I even know how to use it's basic functionality, but it's a huge barrier to being involved and efficient on someone's computer.
There were the pairs the insisted on using vim[1]. There were the pairs that hogged the keyboard. I'm sure there were other things that frustrated me about it (it's been a long time since this was an every day thing now). In the end though, I opted out of pairing, first by taking a devops role at the same company that didn't require it, and later by not applying to any company that had that as a requirement.
To be clear, I'm not against pairing occasionally, but overall I prefer to be alone with my thoughts while programming -- not having to negotiate every little thing with a new pair.
If that doesn't suit the company, then so be it.
[1] I have nothing against vim, and I even know how to use it's basic functionality, but it's a huge barrier to being involved and efficient on someone's computer.
Heh. I have to wonder if the pairs that insisted on using vim might be using that as a politically acceptable way to avoid pairing!
I worked with some vim power-users (I was definitely not one myself), and learned a lot from them by accommodating their preference. Similar results for other tools that I might not have picked up on my own. The only thing I drew the line at was switching to Dvorak with the one dude who carried his own special keyboard around with him. Even that I consider a missed opportunity, but I knew it would have wrecked my productivity at first, and it would have confused my muscle memory for QWERTY for the other 80% of my work week.
I know people that feel that way about it. I can't argue, I also had some really great pairing sessions where I learned a lot. On balance though, it was not what I wanted out of programming.
I have no problem with people that want to do consensual pairing (heh). To make that a focus for their career. It just wasn't for me.
I've ended up going in a different direction now building a startup.
I have no problem with people that want to do consensual pairing (heh). To make that a focus for their career. It just wasn't for me.
I've ended up going in a different direction now building a startup.
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.
Software engineers tend to be less comfortable socially so I imagine other people share this perspective.
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.
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.
I want to see a documentary about Larry David working at such a cult company for a month.
Automatic material for two HBO seasons.
Automatic material for two HBO seasons.
I worked at ThoughtWorks for three years, and -- like everything else XP -- pairing was very much the norm, for the software engineers, and I believe on the whole it worked to our benefit. I am off-the-chart introverted, so the forced intimacy aspect was a nightmare, but I balanced that emotional downside with the intellectual upside of learning a ton of things I might not have otherwise from the folks I paired with.
I've found pairing really useful for certain activities. If I'm working on very critical code or if I need to churn something vast out quite quickly, then pairing has served me well. As a new generation enters software I've noticed there's some differences, but it follows the same theme. Aside from pairing, they like to watch people code. Notably, I had a codebase that had been through a POC but lacked some E2E tests, so I streamed myself writing tests and refactoring code to make it more testable. The engineer picked up on the tools I was using, what I was doing, why I was doing it, and got to see me make mistakes. I think this is yet another avenue where we have opportunities to engage young devs and onboard them more quickly.
As someone that loves and suggests pairing, I'll pass on this:
- Never mandate pairing, authorize it. Some people really don't like pairing and will just complain endlessly.
- If you authorize pairing, find two people who are really good at it and have them train people on how to do it with your equipment and your environment.
- Personalities that clash on a team will predictably not pair well together.
As someone that loves and suggests pairing, I'll pass on this:
- Never mandate pairing, authorize it. Some people really don't like pairing and will just complain endlessly.
- If you authorize pairing, find two people who are really good at it and have them train people on how to do it with your equipment and your environment.
- Personalities that clash on a team will predictably not pair well together.
As an introvert with a family needing random breaks through the day, if this became the standard I would immediately leave the software industry.
I paired at HMRC (the UK's IRS) for about four months. I quit when I was an anxious, depressed wreck who couldn't face going to work anymore. It was a completely soul destroying experience.
The emotional labour involved in managing colleagues (especially those who are less experienced) all day every day is so intense I could barely function outside of work. Steering people towards solutions when they were hung up on irrelevant stuff, explaining things to people who were themselves exhausted in the same way I was, remaining engaged when my screen share was hijacked yet again by someone who "just" wanted to show me something.
I have no idea how the author lasted so long. It took me less than 100 days of pairing (partly through a northern English winter) to quit.
Added to the above, the 'standard' Zoom caveats apply, too: https://www.bbc.com/worklife/article/20200421-why-zoom-video...
The emotional labour involved in managing colleagues (especially those who are less experienced) all day every day is so intense I could barely function outside of work. Steering people towards solutions when they were hung up on irrelevant stuff, explaining things to people who were themselves exhausted in the same way I was, remaining engaged when my screen share was hijacked yet again by someone who "just" wanted to show me something.
I have no idea how the author lasted so long. It took me less than 100 days of pairing (partly through a northern English winter) to quit.
Added to the above, the 'standard' Zoom caveats apply, too: https://www.bbc.com/worklife/article/20200421-why-zoom-video...
> There are people who can pair indefinitely, for years. Who don’t experience the most demanding version of it often. Whose recovery capacity comfortably outpaces the demand.
I've paired for years, at two companies, but I have no personal sensation of "recovery capacity", because I'm an extrovert, and pairing gives me energy, instead of draining it away. One of my biggest complaints with my current company is that pairing is never done.
Extroversion is nothing but a neurological condition from birth.
Pairing is awesome for some, and torture for others.
Another benefit is the ability to work productively in the noisy Great Hall offices into which careless management and high office rents conspire to confine us. Instead of requiring the dead silence I need for solo concentration, I only need to be able to hear my pairing partner over the constant din of telephone calls, and reviews of last night's tacos, aisles away.
I've paired for years, at two companies, but I have no personal sensation of "recovery capacity", because I'm an extrovert, and pairing gives me energy, instead of draining it away. One of my biggest complaints with my current company is that pairing is never done.
Extroversion is nothing but a neurological condition from birth.
Pairing is awesome for some, and torture for others.
Another benefit is the ability to work productively in the noisy Great Hall offices into which careless management and high office rents conspire to confine us. Instead of requiring the dead silence I need for solo concentration, I only need to be able to hear my pairing partner over the constant din of telephone calls, and reviews of last night's tacos, aisles away.
I was a Pivot - this article rings true. When I first joined people would often describe with joy how exhausted they were every single day for months when they first joined, as though it was evidence of learning and growth. That’s only true sometimes. What I realized is that it doesn’t actually stop being exhausting, people just adapt. There is a difference between being tired because I applied myself, did something meaningful and useful, and learned something new, compared to just being tired from navigating personal interactions all day every day.
It's a clickbait title, but he does also address the benefits of pairing. He does highlight the importance of not always pairing. He does not say not to pair.
I think what would alleviate most of his issues is having frequent breaks. 10 or 30 minutes here and there all day, or even an hour before resyncing is essential. Especially now with remote pairing.
I think opt-in pairing is bad. It essentially means, rarely pair apart from on hard things which is not pairing.
Opt-out is better. Then for some tasks you don't have to pair, whilst for most you do.
Or go full mob programming and allow people to come and go.
I think what would alleviate most of his issues is having frequent breaks. 10 or 30 minutes here and there all day, or even an hour before resyncing is essential. Especially now with remote pairing.
I think opt-in pairing is bad. It essentially means, rarely pair apart from on hard things which is not pairing.
Opt-out is better. Then for some tasks you don't have to pair, whilst for most you do.
Or go full mob programming and allow people to come and go.
I joined a boutique software development consultancy where 90% time is spent doing pair programming. It works out well for them since they only take people who like the idea and process of it. I saw one guy leave after a short time because it wasn't for him and it's ok, this is why there is the probation period.
The company has been successful here - our clients like us, they say we are the only partners they have had who actually deliver what they promise, etc
Pair programming is great! When you click with the person you're paired with. When you're with someone who you don't like/is defensive, it's terrible.
I used to work at a startup where I was the most senior engineer below one of the founders, a guy who happened to be remote, thousands of miles away, except about 2-4 times a year when he would fly in for a week or so and share my office with me. He was very enthusiastic about pair programming and we would do this for a couple of days every time he was in town, and afterwards would rave about how thrillingly productive it was. Except it wasn’t really true. I did really enjoy us putting our heads together and solving problems, and a day pairing really did feel more productive in absolute terms than what I would accomplish on my own, but more than twice as productive? Not a chance. More than twice as exhausting? Definitely. 4-8 days a year is about all I could take of that.
PS my theory about why he found it so invigorating and productive was that normally, he was too busy to ever spend an entire day writing code. He would be interrupted with meetings and questions all day. The difference when we were pairing was that he was “hiding out” for an entire day with his head in an IDE and shutting everything else out. I suspect he’d find it equally invigorating if he had the ability to do that on his own.
PS my theory about why he found it so invigorating and productive was that normally, he was too busy to ever spend an entire day writing code. He would be interrupted with meetings and questions all day. The difference when we were pairing was that he was “hiding out” for an entire day with his head in an IDE and shutting everything else out. I suspect he’d find it equally invigorating if he had the ability to do that on his own.
I had a great time pairing with a few individuals from my past, and I'd describe the sessions as playing a coop game with friends. It was fun to team up and figure out a problem and build something; the shared joy of overcoming some hurdle.
Similarly had good experiences 'mob' programming, 7 of us in a conference room focused on building out some new thing. But again, it felt more like hanging out with friends and playing a coop game together.
Similarly had good experiences 'mob' programming, 7 of us in a conference room focused on building out some new thing. But again, it felt more like hanging out with friends and playing a coop game together.
The game mentioned in the article, "Overcooked", actually caused my first and so far only visual migraine. It just completely stressed me out, forcing me to focus on an impossible task. Suddenly my vision looked like someone threw a wiimote into a TV.
I think pair programming is nice when cracking a tough nut of a problem or doing something highly safety-critical, but it's very taxing and there's no way I could do it all day long.
I think pair programming is nice when cracking a tough nut of a problem or doing something highly safety-critical, but it's very taxing and there's no way I could do it all day long.
“Teams had half as many workstations as they had engineers.”
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.
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.
Literally half the number of workstations. No option but to pair. I would find that oppressive.
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.
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 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.
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.
Not necessarily.
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.
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.
I couldn't even work efficiently without my custom setup (keyboard layout, editor configuration, hardware even).
I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate.
If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out.
The biggest thing is you need a team that can trust and support each other.
If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out.
The biggest thing is you need a team that can trust and support each other.
> unless someone can convince me that specifically pairing is causing the burn out
If someone tells you something is causing them anxiety and stress can't you just accept that rather than requiring to be 'convinced'?
You say you want a team that supports and trusts... yet you don't believe people when they say something's causing them pain.
If someone tells you something is causing them anxiety and stress can't you just accept that rather than requiring to be 'convinced'?
You say you want a team that supports and trusts... yet you don't believe people when they say something's causing them pain.
It's not that I don't trust the burnout, but I want to know what aspect is causing burnout. Is it talking all day? Is there stress because someone is watching you work? Are you not taking enough breaks? These things aren't all specific to pairing, which means that pairing wouldn't always be the issue.
Sure, some people are just not the type of people that are good at pairing, and that's valid, but it's important to identify the problem. That's where trust and support comes in. If you can't talk about why you are feeling burnt out with your team, then there is a deeper issue that your team needs to figure out.
Sure, some people are just not the type of people that are good at pairing, and that's valid, but it's important to identify the problem. That's where trust and support comes in. If you can't talk about why you are feeling burnt out with your team, then there is a deeper issue that your team needs to figure out.
The author explains it well IMO. Mentally computing an appropriate response to present to another human takes energy. The more different that human than you, the more energy. There'll be some outliers that are inordinately drained by pairing.
I agree that if someone can't talk about why they're feeling stressed by their work environment then it's a deeper issue than just a personal one. I would point to leaders whose lack of understanding of higher order truths about humans, like that humans are different and space needs to be permanently held for those differences to be surfaced and coalesced, can cause their well intended questioning to come across as personal attack, thereby incentivizing the team member to stay quiet.
Trust is the end state of solving a communication problem. But it's a systemic quality and needs to be cultivated from the system as a whole, not any one member.
I agree that if someone can't talk about why they're feeling stressed by their work environment then it's a deeper issue than just a personal one. I would point to leaders whose lack of understanding of higher order truths about humans, like that humans are different and space needs to be permanently held for those differences to be surfaced and coalesced, can cause their well intended questioning to come across as personal attack, thereby incentivizing the team member to stay quiet.
Trust is the end state of solving a communication problem. But it's a systemic quality and needs to be cultivated from the system as a whole, not any one member.
> unless someone can convince me that specifically pairing is causing the burn out.
For many people, socialising is energy-draining. Thus pair programming is extra tiring. While I do enjoy pair programming in some circumstances - for particularly tricky problems, or for mentoring - I would struggle (to the point that I would no longer like or be effective at my job) if I had to do it all-day every day. I can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.
For many people, socialising is energy-draining. Thus pair programming is extra tiring. While I do enjoy pair programming in some circumstances - for particularly tricky problems, or for mentoring - I would struggle (to the point that I would no longer like or be effective at my job) if I had to do it all-day every day. I can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.
The whole team definitely needs to buy into the full-day pairing/mobbing. I'm definitely more on the introverted side of the scale, and I can handle things as a daily thing, but I do need a break once an hour or so, and that's the sort of thing your pair-team needs to figure out.
And another thing that's super important to talk about is the metric you mention:
> can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.
Productivity is an interesting thing in software. What is productivity? Is it writing code fast? Is that the most important thing you can do for your company/client?
Pairing and mobbing aren't necessarily performance-oriented, but more on transfer of knowledge. If you work in a company that just wants pure churn of new code without a large amount of knowledge transfer between members, then pairing is just a gimmick and not useful to that company. This is really a case of "use the right tool for the job" - pairing and mobbing won't always make sense if it conflicts with the goals and values of the company.
And another thing that's super important to talk about is the metric you mention:
> can believe that some people can be productive with the distraction of someone else constantly there, but I'm nowhere near as productive as I am working on my own.
Productivity is an interesting thing in software. What is productivity? Is it writing code fast? Is that the most important thing you can do for your company/client?
Pairing and mobbing aren't necessarily performance-oriented, but more on transfer of knowledge. If you work in a company that just wants pure churn of new code without a large amount of knowledge transfer between members, then pairing is just a gimmick and not useful to that company. This is really a case of "use the right tool for the job" - pairing and mobbing won't always make sense if it conflicts with the goals and values of the company.
Lots of people burn out. There's no reason presented to think the author would have had more, less, the same, or no burnout programming on their own. They happened to burn out, and they happened to be pair programming for an extended period of time. Myself and friends have also experienced burn out, and none of us pair programed any significant amount.
I've seen pair programming work when taken only in small doses - "Hey, look at this bug with me for 5-10 minutes" types of doses. It gives you another set of eyes, acts as one step better than rubber ducking, and quickly either gives help or confirms that no, you did not miss anything, so keep digging.
But more than that just isn't a style that works for me.
But more than that just isn't a style that works for me.
If your programming routine is causing someone to go on short term disability because it has caused them significant mental impairment, why was there never a discussion about perhaps too much of a good thing is now damaging our workers? Like, nobody thought to themselves, this is causing actual damage to our workers, and maybe we should scale it back?
It's very hard to imagine how other people experience it, because people's experiences can be so wildly different. My wife can carry on conversations while solving problems and getting her work done. It helps her think. She can also talk all day, quite literally, conversing without pause from the moment she wakes up until the moment she closes her eyes, without feeling that it takes any extra energy. If anything, talking is a bit easier than not talking, and it frees her brain to work more creatively and systematically.
Me, I'm exhausted by conversations that last more than a few minutes, and talking interferes with my ability to think. I have to tell my wife sometimes, "Look, I know you shared this new piece of information with me half an hour ago, but we've been talking about it the whole time since then, so I haven't processed it at all. I don't know how I feel about it. I haven't thought about how it changes things. I'm just trying to force out utterances at the expected conversational rhythm until we stop talking and I can engage with the new information."
These two experiences are so far apart that it's very hard to comprehend someone on the other side. In fact, I think it's even harder for someone like my wife to understand someone like me, because I've had it drilled into me from a young age that my way is not the normal one. Lots of people seek professional help because they are too much like me and want to be more "normal" like my wife. Vice-versa, not so much.
My wife loves me and has been living with me for almost five years, but she is still working to internalize the fact that these differences are real. She still has to fight with her gut-level assumption that I experience conversation much like she does, and if I don't partake, it reflects hostility or indifference, and if I say I can't, I'm malingering. If she still has to consciously override that reaction, imagine a management layer of extroverts whose only exposure to introverts is through managing them. To them, it just looks like some people are adapting and thriving, and others are obstructing and malingering.
Me, I'm exhausted by conversations that last more than a few minutes, and talking interferes with my ability to think. I have to tell my wife sometimes, "Look, I know you shared this new piece of information with me half an hour ago, but we've been talking about it the whole time since then, so I haven't processed it at all. I don't know how I feel about it. I haven't thought about how it changes things. I'm just trying to force out utterances at the expected conversational rhythm until we stop talking and I can engage with the new information."
These two experiences are so far apart that it's very hard to comprehend someone on the other side. In fact, I think it's even harder for someone like my wife to understand someone like me, because I've had it drilled into me from a young age that my way is not the normal one. Lots of people seek professional help because they are too much like me and want to be more "normal" like my wife. Vice-versa, not so much.
My wife loves me and has been living with me for almost five years, but she is still working to internalize the fact that these differences are real. She still has to fight with her gut-level assumption that I experience conversation much like she does, and if I don't partake, it reflects hostility or indifference, and if I say I can't, I'm malingering. If she still has to consciously override that reaction, imagine a management layer of extroverts whose only exposure to introverts is through managing them. To them, it just looks like some people are adapting and thriving, and others are obstructing and malingering.
This reads like my worst nightmare.
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.
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.
I'll confess my bias up front: pairing has never worked for me, and I really just can't write serious code unless I'm in my own head.
Having said that, let me now ask pairing proponents: can you give me a rough idea of what you believe the economics to be? Because from my perspective the two people working together on the same program need to deliver value twice as quickly as a solo programmer merely to break even. Based on what I've seen my median estimate for how much quicker things go is ballpark 1.25x, and then throw in some amortized benefit for knowledge transfer and camaraderie. But in my biased opinion find it a stretch that you even hit break-even with high probability.
So, I would love to hear from pairing proponents how they think about the development economics and the size of the win.
Having said that, let me now ask pairing proponents: can you give me a rough idea of what you believe the economics to be? Because from my perspective the two people working together on the same program need to deliver value twice as quickly as a solo programmer merely to break even. Based on what I've seen my median estimate for how much quicker things go is ballpark 1.25x, and then throw in some amortized benefit for knowledge transfer and camaraderie. But in my biased opinion find it a stretch that you even hit break-even with high probability.
So, I would love to hear from pairing proponents how they think about the development economics and the size of the win.
[Edit: Article is spot on]
In my experience, pairing works really well to deal with ambiguity, as in problem solving.
In my experience, management often mistakes ambiguity with uncertainty when allocating resources to a project or engagement. This results in terrible pairing experiences where you've been allocated to a project where your normal tech. stack simply doesn't apply. You're suddenly in the weeds learning a new language / framework / deployment-environment playing catch-up with your pair, while your pair is trying to burn-down the actual task/story at hand.
Yes, Software engineers should be willing to learn new things. But, No, I'm not willing to sacrifice the primary psychological safety of knowing "I'm qualified to do my job" just to keep a cadence.
In my experience, pairing works really well to deal with ambiguity, as in problem solving.
In my experience, management often mistakes ambiguity with uncertainty when allocating resources to a project or engagement. This results in terrible pairing experiences where you've been allocated to a project where your normal tech. stack simply doesn't apply. You're suddenly in the weeds learning a new language / framework / deployment-environment playing catch-up with your pair, while your pair is trying to burn-down the actual task/story at hand.
Yes, Software engineers should be willing to learn new things. But, No, I'm not willing to sacrifice the primary psychological safety of knowing "I'm qualified to do my job" just to keep a cadence.
Requirement to pair is discriminatory for neurodiverse people. I always quit a company when they forced me to pair. I don't mind from time to time, but often it ends being me doing all the work but sharing the reward with other person that contributed little.
I find pair programming a useful tool. It's great as patterns and practices are getting stood up on a team, for ramping new members, disseminating knowledge or for wrestling through novel code. As the article gets it, at can also be very emotionally draining so team members don't reach for enough on their own. As a lead, I regularly encourage or instruct my team to pair. However I also wouldn't make it an "always on" policy. It IS exhausting, and it is inefficient in many cases.
We've also adopted a few alternative practices (especially frequent "mob coding" sessions where we work through problems as an entire team rather than just pairs) that people find less draining.
We've also adopted a few alternative practices (especially frequent "mob coding" sessions where we work through problems as an entire team rather than just pairs) that people find less draining.
Is it really true that Pivotal had only n/2 workstations for the n devs? That seems to be an extreme arrangement (pardon the pun). I can see the benefit of pairing when
(a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the area well may be beneficial, because you get code-review while solving the problem. And your non-keyboarding partner can see things that you are too deep in to see.
(b) an interviewing technique to see how you collaborate and approach problem-solving (once again, there's an element of non-open-ended problem-solving here). I must hasten to add that this should not be the sole evaluation method in an interview, because many people can't collaborate impromptu with someone they do not know, and many people prefer to let their minds wander in search of a creative solution, which can look like cluelessness in an interview situation.
(c) inducting a new developer into a team: by watching a veteran at work and the techniques he uses, a new hire can quickly absorb best-practices that will bring his productivity to a high level in a relatively short time period. Once again, this must be done for shorter time-periods: it's pretty much impossible to maintain a high level of engagement with a problem for hours on end. Putting the problem in your back pocket, and sleeping on it often leads to flashes of insight that can deliver robust, clean code (the first system or solution to a problem is almost never the best, particularly in software or schema design).
I can't imagine many other scenarios outside of these, particularly for routine software development work, especially when code review by peers is a mandatory step in the process. You are probably removing the element of slow thinking, which can improve product considerably, by forcing pairing all day, every day.
How does such a wonky culture take root in a fairly large organization anyway? A lot of senior developers would just refuse to work for such an organization!
(a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the area well may be beneficial, because you get code-review while solving the problem. And your non-keyboarding partner can see things that you are too deep in to see.
(b) an interviewing technique to see how you collaborate and approach problem-solving (once again, there's an element of non-open-ended problem-solving here). I must hasten to add that this should not be the sole evaluation method in an interview, because many people can't collaborate impromptu with someone they do not know, and many people prefer to let their minds wander in search of a creative solution, which can look like cluelessness in an interview situation.
(c) inducting a new developer into a team: by watching a veteran at work and the techniques he uses, a new hire can quickly absorb best-practices that will bring his productivity to a high level in a relatively short time period. Once again, this must be done for shorter time-periods: it's pretty much impossible to maintain a high level of engagement with a problem for hours on end. Putting the problem in your back pocket, and sleeping on it often leads to flashes of insight that can deliver robust, clean code (the first system or solution to a problem is almost never the best, particularly in software or schema design).
I can't imagine many other scenarios outside of these, particularly for routine software development work, especially when code review by peers is a mandatory step in the process. You are probably removing the element of slow thinking, which can improve product considerably, by forcing pairing all day, every day.
How does such a wonky culture take root in a fairly large organization anyway? A lot of senior developers would just refuse to work for such an organization!
> Is it really true that Pivotal had only n/2 workstations for the n devs?
By and large yes this is true. There were some teams that experimented with odd numbered sizes and others that were split remotely that required more to facilitate all pairing rotations.
> How does such a wonky culture take root in a fairly large organization anyway?
I suppose wonkiness is in the eye of the beholder. The company was simply built around XP, with pairing being a core part of that. I went to Pivotal (2015-2019) because I wanted among other things, to try pair programming from some of the most committed to it. In that way, it's self-selecting. It was baked in throughout the interview process. Sure, there are a lot of senior engineers who will never get on board with pairing, but there also are far fewer companies that commit to it in the same way.
By and large yes this is true. There were some teams that experimented with odd numbered sizes and others that were split remotely that required more to facilitate all pairing rotations.
> How does such a wonky culture take root in a fairly large organization anyway?
I suppose wonkiness is in the eye of the beholder. The company was simply built around XP, with pairing being a core part of that. I went to Pivotal (2015-2019) because I wanted among other things, to try pair programming from some of the most committed to it. In that way, it's self-selecting. It was baked in throughout the interview process. Sure, there are a lot of senior engineers who will never get on board with pairing, but there also are far fewer companies that commit to it in the same way.
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...
I just can't do pair programming. I like doing my work, testing a bit and throwing it over to CI, QA, etc. Sorry, I'm just not that social, nor do I want to be in communication that often with any other human being other than my kids or wife.
Pairing all day, every day is a relatively rare version of pair programming. In every case I’ve seen, pair programming was only done for a few hours a day or in select circumstances such as architecting a system.
Browsing the comments, that seems to agree with what most people have experienced at their jobs, with the exception of a few horror stories about companies that forced 8-hour per day pairing and paid the price for it.
Browsing the comments, that seems to agree with what most people have experienced at their jobs, with the exception of a few horror stories about companies that forced 8-hour per day pairing and paid the price for it.
I think it says a lot that there are 156 comments in this thread and introversion is only mentioned three times including this comment so far. More people need to take personality tests lol.
You can't operate indefinitely this way as an introvert, it's physically impossible. Extroverts simply can't comprehend how impossible this level of interaction on a daily basis is for an introvert. Programming is an inherently internal process which is introversion, and naturally draws people that lean more towards introversion to this field. I'm not dismissing the benefits of pairing, but to do it while completely ignoring the needs of the target audience (predominately introverts) is ludicrous and of course this burns people out.
Introverts, to varying degrees, expend energy in the presence of other people. They have to be alone to recharge. There is often a misunderstanding that introverts are just shy, this is a fundamental misunderstanding. Shyness often accompanies introversion but they are fundamentally different aspects.
Extroverts are the opposite, they gain energy when interacting with others. Most people are some form of omnivert, certain interactions can drain them and other interactions can give them energy.
No matter how beneficial pairing is it will fail if it doesn't learn to adapt more to the needs of the core user: introverts.
You can't operate indefinitely this way as an introvert, it's physically impossible. Extroverts simply can't comprehend how impossible this level of interaction on a daily basis is for an introvert. Programming is an inherently internal process which is introversion, and naturally draws people that lean more towards introversion to this field. I'm not dismissing the benefits of pairing, but to do it while completely ignoring the needs of the target audience (predominately introverts) is ludicrous and of course this burns people out.
Introverts, to varying degrees, expend energy in the presence of other people. They have to be alone to recharge. There is often a misunderstanding that introverts are just shy, this is a fundamental misunderstanding. Shyness often accompanies introversion but they are fundamentally different aspects.
Extroverts are the opposite, they gain energy when interacting with others. Most people are some form of omnivert, certain interactions can drain them and other interactions can give them energy.
No matter how beneficial pairing is it will fail if it doesn't learn to adapt more to the needs of the core user: introverts.
My experience is that it's best when it happens organically. Enforcing this sounds like a punishment.
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.
As with almost everything, the truth is somewhere in the middle – pairing isn't universally good, nor univerally bad. It shouldn't be done all the time, neither should it never be used.
"There is no silver bullet." Fred Brooks wrote this over 30 years ago, and it still applies.
"There is no silver bullet." Fred Brooks wrote this over 30 years ago, and it still applies.
I sometimes coach new teams on pair programming and XP, so wrote this short article explaining how it works in practice, using snakes:
https://sonnet.io/posts/snakes/
https://sonnet.io/posts/snakes/
Humans are fundamentally meant to interact and collaborate with other humans. Technology has obscured this by empowering us each to be resourceful alone. In the long term, we indeed do operate best collaboratively.
Pairing is hard because it involves two or more brains trying to solve a complex problem live through mediocre sensory and speech motor systems.
Naturally it’s going to work fine for some and be disastrous for others.
Naturally it’s going to work fine for some and be disastrous for others.
[deleted]
Chiming to say that I too have burned out as a result of forced pairing. Will never do it again except on an ad-hoc, limited basis.
I feel like in 2021 I can roundly refuse to engage in pairing and question the experience of anyone suggesting it.
Pair programming was invented so consultant bodyshops can bill customers twice the price for half the mediocrity.
How did this person link the cause and effect?
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.
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.
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.
This story should be in the dictionary under "Cargo cult".
Ding, ding, ding.
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.
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.
Also, is there a pair programming equivalent of the Scrum Master? That would be the chief slack position.
No. That's one of the many differences between Scrum and XP. XP is the feral cousin of Scrum.
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.
I don't know what a "Pivot" is.
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.
> 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?
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
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
Shoot me now
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.