It's official. I'm a better programmer when I'm pairing with someone. Pair Programming (two people, one keyboard) has been around for at least 20+ years, if not much longer. Usually one person types while another person (paces around and) thinks. It is kind of a "driver and navigator" model.
Everyone is different, to be clear, so it's very possible that you are the kind of person who can disappear into a closet for 8 hours and emerge with code, triumphant. I've done this before. Some of my best projects have involved me coding alone and that's fine.
However, just has we know that "diverse teams make for better projects," the same is true in my experience when coding on specific problems. Diversity isn't just color and gender, etc, it's as much background, age, personal history, work experience, expertise, programming language of choice, heck, it's even google-ability, and more!
How many times have you banged your head against a wall while coding only to have a friend or co-worker find the answer on their first web search?
Good pair programming is like that. Those ah-ha moments happen more often and you'll feel more than twice as productive in a pair.
In fact, I'm trying to pair for an hour every week remotely. Mark Downie and I have been pairing on DasBlog on and off for a year or so now in fits and starts. It's great. Just last week he and I were trying to crack one problem using regular expressions (yes, then we had two problems) and because there were two of us looking at the code it was solved!
Why is pair programming better?
Here's a few reasons why I think Pair Programming is very often better.
- Focus and Discipline - We set aside specific times and we sprint. We don't chat, we don't delete email, we code. And we also code with a specific goal or endpoint in mind.
- Collective ownership - I feel like we own the code together. I feel less ego about the code. Our hacks are our hacks, and our successes are shared.
- Personal growth - We mentor each other. We learn and we watch how the other moves around the code. I've learned new techniques, new hotkeys, and new algorithms.
Let's talk about the remote aspect of things. I'm remote. I also like to poke around on non-work-related tech on the side, as do many of us. Can I pair program remotely as well? Absolutely. I start with Skype, but I also use Google Hangouts, Join.me, TeamViewer, whatever works that day.
If you're a remote person on a larger team, consider remote pair programming. If you're an consultant or perhaps you've left a big corporate job to strike off on your own, you might be lonely. Seriously, ask yourself that hard question. It's no fun to realize or have to declare you're a lonely coder, but I am and I will. I love my job and I love my team but if I go a day or two without seeing another human or spending some serious time on Skype I get really tense. Remote pair programming can really reduce that feeling of lonely coding.
I was at a small tech get together in Atlanta a few days ago and I knew that one person there was a singular coder at their small business while another at the table was an emerging college student with an emerging talent. I made a gentle suggestion that maybe they consider pairing up on some side projects and they both lit up.
Consider your networks. Are there people you've met at conferences or at local user groups or meetups that might be good remote pairing partners? This might be the missing link for you. It was for me!
Do you pair? Do you pair remotely? Let us all know in the comments.
* Stock photo purchased from ColorStock - Your customers are diverse, why aren't your stock photos?
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
Personally i find the pair programming to be challenging beyond belief, given my introverted nature. It feels like an invasion of my personal space, and I feel not as though I'm contributing to anything, so much as being analysed critically.
I prefer to code alone, and I have no problem at all with focus even I do. When I pair, I feel LESS focused in fact as I'm constantly worried about what the other person is going to think of my code, and my coding habits.
These are just a couple of reasons why I don't pair. I've got others, but they tend to be, I guess, personality effects. I'm not built to code in a pair, but I'll happily declare that I can write great code solo, and I work very well as part of a team.
I guess my point is that it's not for everyone, and while it's a real benefit to some, you should absolutely NEVER assume that it's going to work for everyone.
I also find it frustrating sometimes, as I have a hard time both listening to someone talk and also reading code at the same time. And I can never really get into a good flow state when I'm interacting with another person so much. When I'm in "flow", I feel invigorated and energized at the end of the day. When I can't get into "flow", I often feel exhausted by the time I go home.
I do think pair programming has value for sharing knowledge. I'd recommend pair programming for an experienced programmer mentoring a junior, a new employee who needs to learn the system, or for anyone who's just plain stuck and needs a second pair of eyes on their design. In the latter case, pair programming can be like a sort of corroborative code review. However, assuming I and my prospective partner are both familiar with the system, have similar experience and skills, and don't have any roadblocks, I feel I'm better off working on my own.
Personally I think all smart ideas and solutions come when you relaxed home and have all good ideas for next day.
So if pair programming is something good can be if you feel relaxed and feel if it free up the load for brain by being two.
The goal is information sharing, democratizing ownership of code as Scott mentioned in the post, but also improving maintainability and reducing chances of bugs, handling edge cases, etc. It's more man hours invested up front to save potential totally many more, critical bugs oremergencies, data loss, revenue loss, angry customers etc.
I pair extensively on a legacy, convoluted, spaghetti, brittle code base. We're constantly catching things for each other that would have very real consequences. Code reviews are great, but you're head just isn't quite as deep in it.
I even paired on the creation of a Pair Programming Fundamentals course on Pluralsight with Steve.
i would NOT want to pair program with myself.
perhaps it's because i'm in my 70th year...
more likely it's because of the way that i think...
or perhaps it's OCD...
or perhaps it's because i'm a control freak...
most likely, it's because i'm a typical Taurus.
i do my best to practice schizophrenic programming...
one me personality codes an application facing (a.k.a. programmer a.k.a unit) test
against some non-existent black box...
the other me personality codes the stuff for inside that black box.
what would be interesting would be if we could corral 3n sets of twins...
one third would pair program together,
one third would program as individuals, and
the last third would pair program with someone who is not their twin.
the results of such an experiment could contribute harder evidence
regarding the efficacy or lack thereof of pair programming.
if not, perhaps it should have been ... it was written SINGLE SPACED but is rendered DOUBLE SPACE.
SINGLE SPACE line 1
SINGLE SPACE line 2
SINGLE SPACE line 3
Pairing also makes your own brain work even more. After a day of pairing you can feel positively wasted, but good at the same time.
Pair whenever you get the chance to do so. it's a great way to learn find a good solution.
Pairing helps us find potential issues with our code earlier than if we were solo (in software, it's much cheaper to fix early than later).
Pairing means more than one person has deep knowledge of the code _before_ it's checked in.
Pairing means I can learn from my co-workers as I go along, often finding that human knowledge sharing is faster/better than researching.
Pairing remotely using a screen sharing is a fantastic experience - you can both be sitting/standing at your own desks and looking straight at the code in question. If you need to have another view onto the code - say when one pair is researching something - then you can do that without disturbing the flow of your pair partner.
Slightly off topic, but we also regularly bring our testers in for a review _before_ we check in. Getting tester input at this early stage is valuable for the dev pair and often highlights areas for improvement. It also helps us be sure that the tests we've written are correctly targeted and adjust if needed.
I would love to find a person who enjoys pair programming. I have been doing development only for 2 years and when you are new to programming there are so many unknowns. Because I truly care about code and see it as a craft often times I wish I had a person who would check the code and give me advice on best practices and explain the whys and since I had pair programming couple of times in meetup events I noticed I learned so much more and so much faster. All I want is to write a quality code and if someone has a passion for teaching and guiding because it is beneficial to them as well, please leave a comment and we can start any project or contribute together to any open source.
In my current job the dev team is exactly me and I feel like it's the least productive I've been in years. Any issues are stuck with me banging my head against a wall to figure them out, no help, no one to explain the issue to and suddenlt realise the fix mid sentence.
Worse is the fact I'm a lone programmer in a room of IT people. The atmosphere is all wrong and I feel alone in a room full of people, and I seem to be making the gap wider. It must only be a matter of time before something gives.
I believe that pull-requests with "peer reviewing" provides more code quality (as more people will be able to look at the changes you are trying to check in) than just having two people (the pair) review their own changes and check that in directly into the codebase.
A specific recent project I worked on enforced "religious pairing”, but I was the only senior amongst a small group of developers that were technically of beginner/junior level. As one would expect, the resulting code quality was quite low given the lack of knowledge of the platform, tools, patterns and practices.
If on the other hand you have a team of seasoned, experience developers who know what they are doing, what will pairing accomplish there? Tech discussion are quite useful and can be had without the need to pair with another person.
Then you have personality differences, different setups, different schedules, etc. How do you handle all of those? I personally like to use my own machine, set up with my own tools and settings, and going to work on someone’s else machine just feels like an impediment as I have to learn how that person works and try do adapt.
One thing is for sure: pairing has to be something that EVERYONE on the team wants to do, and not something you can enforce on others just because that’s a decision by the majority. That’s just asking for problems, as you’ll always find yourself with a bunch of unhappy devs!
The fact that we don't see other disciplines with a similar practice makes me suspicious. I don't see pair accounting, or pair plumbing, pair architecture, or pair sculpting. What's the unique character of programming that requires pair programming?
In my team we got a dedicated machine with dual keyboards and screens.
I have problems understanding that people see nothing positive in pairing. I will not go into that discussion because I think it will be a discussion about people not pairing. :p
On the other hand solo-diving is often extremely satisfying. :)
Perhaps there should be pair accounting, pair plumbing, etc. I don't even want to count the number of times my accountant has screwed something up only for me to have to find it, or the plumber doing a crappy job. Two heads are always better than one.
My team at work also does an hour a day of Mob-Programming where all work on a piece of code together. This helps us stay on the same page and learn from each other.
I'd love to see you at a tech gathering in Atlanta the next time you're in town.
- How to convince business guys that two folks work on a single story?
- Your pair shall be good programmer & frequency shall match ..
I liked reading this article. Thanks for sharing
The benefits have been tremendous and in a lot of varied ways. I am now better at job interviews where I am expected to code in front of people. That was unexpected, but makes sense when you think about it.
It's a bummer when you have a personality conflict, though. You really dread that 4 hours spent hip-to-hip with someone that has a weird verbal affect or whose desk is gross.
Comments are closed.