I used to be a zealot. I had found the religion of XP, and I enforced pairing on teams I was hired to coach. Many people were happy to be exposed to it, but many weren’t. Of those, some were better for the experience, some weren’t. In either case, it was massively disrespectful of me to force it on people. Certain kinds of people are drawn to programming. Asking some of those people to pair all day every day is tantamount to asking them to switch careers. I for one don’t have the emotional energy for it any more. Having said all that, I would encourage any skeptics to give it a try, in the right environment with the right teammates. It can really teach you a lot in a short period of time.
I feel the more general lesson here is that zealotry in our industry is almost always a bad thing. Whether it be in technology choices, development paradigms, project management techniques, training strategies, or even just how you deal with your staff and coworkers.
Whenever I come across a zealot in a professional setting, I'm fairly certain they're intentionally ignorant toward better ways of tackling certain problems (big red flag).
I agree, although I would qualify your last statement a bit to allow for (a) the zealot is usually well-intentioned, and (b) the zealot is usually not intentionally ignorant, but rather hasn’t yet learned that context matters.
I used to love the idea until I really understood what people meant by it. It would be a career change and I'd hate it.
What I want is a wingman, not a co-pilot. Someone I'm paired with who learns my code intimately and I learn theirs intimately and we are always supporting each other in PRs and design chats. But ultimately we fly our own aircraft our own way.
I'm glad I worked in a pairing-heavy environment for awhile but I'm very glad I no longer do. I learned a lot incredibly quickly from the more senior folks I was able to pair with at the time, but the idea of doing it full time now fills me with dread.
In general, I'm happy to say "to each their own", but pairing is very often not a personal choice. Your zealotry may well affect me! Happily, pairing doesn't seem to be taking the industry by storm at the moment, so I'm not too worried about it, but when I started my career (mostly in Ruby) it seemed like a real possibility, which I came to fear the more I realized how poorly it suited me emotionally.
I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I really miss pairing.
I feel that most of the problems my team has now would be easily solved by pairing. Things like shared standards (not just syntax but architectural approaches that are hard to automate), testing (you keep each other honest), and faster code review. Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. People don't have a good idea what anyone else is working on (beyond the few that seem to do most of the code reviews). Swapping pairs every day or two easily solves these problems.
Things like on boarding new employees is just so much faster that it's a no brainer to pair, especially when they're starting out. Junior developers learn so much faster by working directly with a senior developer. Sure, it might slow the senior down (very little in my experience) but it makes the junior developer so much more productive in the long run.
Pairing is mentally exhausting at first and I can understand that it isn't for everyone. Most people hate it at first, especially if they have a bad setup. Most people I work with seem to think it means 2 people crowded around a single laptop. Setting up real pairing station with multiple BIG monitors and 2 keyboards and mice is crucial. After you get comfortable with it, the "always on" feeling goes away and it just becomes an enjoyable day working closely with your colleagues. If you really give it time, I feel it's the "right" way to develop software.
Switching a team to pairing might not be the right decision for everyone. Some people are just uncomfortable working with others. I'm not sure those people will be super strong members of most teams anyway, but they can certainly be successful in some organizations. If you build your team around pairing and select for it in your interview process, you can have really great results.
Your experience is not universal. I paired for long enough to get comfortable with it. It never stopped stressing me out. I believe (and have years of performance reviews that suggest) I'm a very strong team member. But I work better asynchronously through text than synchronously through speech. It gives me time to get my thoughts in order before writing them down, rather than racing to simultaneously form thoughts and interject them into the flow of conversation.
I believe all of the benefits you list are real, but that pairing is not the only way, and in my opinion not the best way, to achieve them (with the exception of on-boarding junior employees). I have found architectural standards to be well served by a lightweight design documentation and review process. This has the advantage that the design artifact continues existing somewhere, rather than just being a communicated consensus between pairing partners. People can be kept honest in testing through good code review. I don't think the goal of code review is to make it fast. I think of a good code review as an asynchronous low pressure pairing session.
I'd like to just be happy for people to pair if they enjoy it, but sometimes it seems like advocates for pairing don't feel the same in the reverse. For instance, your reasonable seeming comment suggested that those of us who don't enjoy it so much are weak team members who should be weeded out during interviews.
This 1000 times. It should be the top comment on the page. The desktop setup is crucial. 90% of the time when I ask companies if they do pairing and I ask them to describe the setup, it is two people crowded around one laptop and that never works. I can't imagine watching someone type like that.
I'd add a few other things that help a lot... a very good PM writing stories that pairs can pickup and run with (and a good management tool everyone knows how to use properly, like Pivotal Tracker), a Monday iteration planning meeting, a Friday retrospective (with whiskey!) and ping pong tables to blow off steam, as a pair.
It sounds so cultish meta silly .com programmer... and it is... but it also works really well as long as the majority buys into it.
One way I found to introduce this sort of system into a company is to just start with one pairing station (the computer setup described above). Tell people that when they want to pair, they can use it all they want. My experience is that soon enough, you'll be getting requests for more stations.
I'm in the same boat. After pairing for many years I've been soloing for a year now.
It's been good in some ways to (re)learn to work on my own, but man, it's such a dumber, slower and duller way to work.
I understand it's not for everyone, and that's perfectly fine. I just wish there was an easy way when job hunting to find the pair programming jobs! Why is it so hard??
> Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed.
I think it's admirable to want to spread knowledge around as much as possible, I think having individual developers "own" specific applications or features is a net benefit. Sure if a developer leaves, they take their knowledge with him and someone else has to get up to speed, but that will necessarily happen anyway.
There is only so much room in your brain; the more features or projects you work on, the less you remember about any of them. Being able to go to the feature X "guy" most likely means the problem will be solved significantly faster. That person's caches are already primed, the pages are loaded from disk, and they can hit ground running. That is a much better case to optimize for than the off chance somebody gets hit by a bus. We also know that multitasking is bad for productivity so the less people have to focus on the better.
I think what's really nice with pairing is that you can have feature ownership and spread knowledge really easily.
The way I've done it in the past is that a feature will have an "anchor" or someone who owns it. They'll work on most of it and be in charge of interfacing with product on how it should work.
That person would switch pairs every day, working with a few people who then pick up some of that context. Being hit by a bus is the classic example, but a more realistic one is that the person goes on vacation. Now, instead of just being 1 person with deep context on that feature, there's potentially a few others that will know it well enough to solve the problem.
The people that are constantly switching will eventually own a feature and won't have to multitask all the time. Also, when you're pairing with someone, you get to share some of the focus with that other person, which I've found to make switching contexts a lot easier.
You are right, pairing often fails because companies don't bother to set up the right environment and processes and fine tune them. It's probably the same with things like scrum or remote work. They can work well if the company puts some honest effort into making them work. Most of the time they don't so everything falls apart though
I loved pairing and I want to do it again. Now I work as a sales engineer and look at other peoples’ code all the time, but don’t write much myself.
My personality seems to be one that gets more energy from interaction with other people. I think they call that extroversion. I’d imagine that for folks like me, pairing is great.
It’s probably not that simple. But surely there are personalities that take well to it and those that don’t.
I find pairing with anyone that is significantly outside the range of your competency level, to be extremely frustrating.
You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile.
IMO - pair programming is over-hyped. I often find that I produce better, more reliable code, with the more space and more time I am given. I agree that pair-programming can rock in certain circumstances - but you need developers that have a certain level of synergy, you can't force it.
> You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile.
If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.
It is completely driven by senior developer. Many students find such pedagogy demotivating. They are not getting tasks they could solve autonomously and independently, every their step is watched as they are doing it. So, they don't even have chance to make mistake, realize mistake by themselves and then fix it. Imagine college classes done that way - everyone would rightfully complain.
Motivation and desire to learn are partly function of personality and partly function of environment.
> Imagine college classes done that way - everyone would rightfully complain.
The tutorial method is thousands of years old, actually. I suspect that if one-on-one education was economically feasible it would be the model chosen almost every time.
Having paired with people who don't know what "if" and "for" mean in a software context clear through to individuals who've been in software for longer than I've been alive, I can only say that it works more often than not.
I often hear that pairing would be terrible at this, pairing must be dreadful for that, pairing wouldn't work for the other thing. What these have in common is that they are rejections based on mental simulation of events.
But ... I've actually paired. For years. It doesn't work for everyone but it still works for most people, so long as they learn it from an experienced pair.
It is frustrating to see a thing work, over and over, then be told you must be wrong, it can't possibly work.
Another issue with pair programming - the assumption that the benefits which are potentially produced by pairing, are often baked into estimations regarding quality of work and / or deadlines.
The current product I work on has had a team of - count em - two developers for the past year. I'm the one that is full-stack, so I get to help the less-experienced developer work on our frontend, while I have minimal time to work on the backend solo (for the most part).
My pair programmer partner, also has no interest in learning the new dev-sec-ops our company is pushing - so I get to also solo all of that work.
It's an extremely frustrating / soul-crushing scenario to be in. It's basically punishment for exhibiting competence and willingness.
It's a situation I'm hopefully out of in the next month.
Then - he randomly wants to chime in with tangentially related questions - it's basically all of the pitfalls described in the - working with a junior dev section of the OP's article - except I've tried every one of the tactics described therein, and at some point you have to question whether the junior dev really wants to be a dev or grow at all...
I started with XP way back in 99 after following the discussions on OTUG and then the white book came out.
I PP for 8 -> 9 years. Theres a bunch of things I learnt from that
It is really good for improving everyones skills. There is a fast convergence in good way to do things
The code quality is generally really good and people often develop good habits, everything gets discussed.
It doesn't work so well when people are across different projects, much better if they are all on the same project.
Teams reach a point where it doesn't actually matter if you pair or not, you tend to carry on making good code.
It can slow down experienced devs and they often don't get the same kind of "flow / mental zone" of coding they can get by themselves.
Developers need alone time to do their own coding experiments and to follow their own noses
It 100% has to be done right and people need to be open to the idea, I went into other companies who were trying to do it and it was failing massively. There was animosity and a lack of openness to trying it. People really didn't understand why they should do it, and felt coerced and threatened by it all. Untangling those messes seemed ... unproductive :)
It's exhausting.
These days I don't see the need for full time pairing, I see it more as a tool that has certain outcomes, and you use that tool when you notice certain kinds of problems / weaknesses. I would think that teams should "pair" at some point, and by that I mean watch each other code and have interactive discussion about code as it gets developed.
Pairing with someone you get along with is a great experience. But with a lot of people I find it pretty miserable. I have paired with people who I just almost never agreed with. I am not saying they were bad but I just didn't like their style. There is also the risk of having one very dominant partner and the other one just watching passively (or having checked out already).
The "How to pair with a junior developer" section is extremely considerate, and highlights some behaviours that I know I've subconsciously engaged in that may have negatively impacted a junior dev. Expanding this section would be great.
It actually makes a great reference. Today during a pair session a new developer happen to mention a technology that might solve X, Y and Z.
I think 5 or 10 years ago I would have shut them down - I was much more arrogant back then. Instead in the next few days this person is going to demo something they've built since they are pretty much our team's expert in this tech - since none of the others have used it. If everything checks out, this could very well be our next large architectural shift - and that's incredibly awesome contribution for someone new. Even if it means he'll be putting in a lot of extra work and time - in my eyes that's better than turning him into a robot that wants to check out exactly at 5pm.
I've been pair programming for about 6 weeks now, over Discord. The calling and screen sharing functionalities work so well that my partners and I can join and part quickly and easily. We can get deeply into what we're doing individually. But collaboratively, we can solve problems that neither of us can do alone.
I like this virtual setup for multi-user interaction a lot, and hope more tools, even ones specific to virtual programming environments, come for it soon. Tuple's making a remote sharing tool that looks interesting. What comes to mind for me is a shared 3D Wayland environment, like this https://www.youtube.com/watch?v=_FjuPn7MXMs so, hopefully more people will start focusing on https://github.com/way-cooler/way-cooler and other Rust desktop/handheld application level development.
My best work is when I go off on wild tangents that might not work out (and some don't). I also tend to build wild and then refactor to cleanup later. I'd hate to put someone else through that all the time and I doubt they'd even let me.
While I'm pro-pair programming I totally understand these issues. The way I normally go about it is put it out there that I like pair programming. And if other people in the team feels the same way, usually that just clicks.
I definitely think PP shouldn't be mandated at all. I think too that some of the issues you bring up are very important - especially about the notion that the soft spoken person will usually have their ideas rejected. A lot of developers act in very peculiar ways often because software development shops can be very toxic. Instead of addressing that toxicity, most places end up with a few head honchos. It really is bad for companies actually and can lead to many great budding engineers to leave or get out of the profession, sadly.
We got rid of the bad breath, smelly ass, coffee spill issues associated with pair programming. It's all remote now using VSCode Live Share and something like BlueJeans or Slack calls to facilitate the communication.
How well pairing works also depends on a person's personality. Introverts don't really do well in pairing situations, and especially when paired with someone totally opposite, the pairing essentially becomes a single person coding and the other person just observing and nodding their heads.
Plus beyond introversion, controlling and dominant people make everyone suffer during pairing. Also, shy people non-assertive people loose any possibility of autonomy or independent decision making (they might or might not find it uncomfortable). People who see everything in absolutes are hard to pair with and find it stressful. Extroverts who still like to think about problems silently or explore issues cant do that in pairing either.
The human social issues related to pairing are many more areas then just introversion extroversion.
Along the same lines, this doesn't work if one person is used to working rapidly and the other person takes their time to think things through. I found it only really worked best when I worked with another who worked at a similar pace to mine and we took time to bounce ideas off of each other. We both learned a LOT from each other since we both had strengths in opposing areas
