The case for pair programming
tuple.app
tuple.app
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).
https://amontalenti.com/2012/02/12/xdds
I prefer thought-driven development and design-driven design.
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.
You got the mail on the head! That's exactly how I felt when I was told to pair program at a job for 6 months.
I just wish more people were open to and had the same opportunity.
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.
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.
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.
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??
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.
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.
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.
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.
If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.
Motivation and desire to learn are partly function of personality and partly function of environment.
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.
It's also driven by the company. Sometimes companies make decisions that really impact employee loyalty.
On the other hand, in a review-driven situation, you're back where you started, multiplied by a slow feedback cycle and competing stimuli.
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.
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.
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.
Another great section would be how to identify a pairing that is less than ideal / problematic.
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.
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.
The human social issues related to pairing are many more areas then just introversion extroversion.
Fortunately you needn't look far for good examples of how to do substantive critique; there are some excellent ones in this thread.