Pair Programming: Looking from the Outside-In

Last week I learned more about Pair Programming than I gained from all my previous years of working with developers. (As a Business Analyst, I have never paired for a significant amount of time, but I think I’ll be forcing that issue soon!) My team had an hour-long discussion about pair programming that filled me with new insights, although if you’re into programming and engineering you can follow this reverse engineering tutorial to know how programs work. Here’s a summary of my notes so you can gain some insight into this engineering practice.

Project Background: ThoughtWorks was hired to develop a set of branded websites for our Client. The team was a mix of ThoughtWorkers and Client developers, analysts, and project management. The first few months were pretty rough with a scope significantly bigger than the timeline. Worse, while we thought we could avoid the 15-year old legacy code and a myriad of systems, we couldn’t and it added significant roadblocks. The result is we struggled for a couple months in the middle of the project. We turned things around and were very happy with the end product, which was due to go live in two weeks. Except the project was cancelled!

The team history — struggling against the seemingly insurmountable scope and environment, turning the project around, and the sudden cancellation (for business reasons, nothing to do with the project itself) — built the environment for very open and honest discussions. Of the 25+ people on the project, almost 15 of us met to talk about Pair Programming. Most of the folks were developers, split evenly between the Client and ThoughtWorks. The Client developers were new to paired programming when they started with this project. Their total experience with pairing ranged from 1-7 months. The final third of the audience was spread among QA, BA, an iteration manager (think Scrum Master), and a Client program manager.

I kicked off the meeting by asking the Client devs if they had experience with paired programming before this, what they liked, and didn’t like about the experience. Starting off positive, they really liked the knowledge sharing and the cross-pollination of new ideas and information.

A month later I was exhausted, but I was completely on board.

Then we got honest and they said it was really awkward at first. “Do I touch the keyboard? Do I not touch the keyboard? I was pointing at the screen with my finger and the other person said they couldn’t see what I was pointing at.” Quickly, another Client dev jumped in and said, “It was intimidating. I don’t like to look stupid. When I work on my own it’s a process of doing stupid stuff, it doesn’t work, doing stupid stuff, it doesn’t work, and finally one day it works. It [paired programming] is like a test.”

“I thought the math meant we could do double,” said a third Client dev. “I was not on board and a month later I was exhausted, but I was completely on board. I would not go away from paired programming at all. You have fixed 10 things without even typing anything because you’re pair is catching things.” After a bit more discussion he came back and finished with, “It’s a different math, but I think the speed is double. It’s more efficient. When you’re with a pair, then you are not checking emails, you are not on YouTube. You are not doing any of that. You have almost no waste of time. It’s quite exhausting.”

From one of the ThoughtWorks devs with less than 2-years experience, the comment came “I learned paired programming and when I write code on my own it seems so much slower. If I could sit down with someone I could talk to it would go much faster.”

ThoughtWorks’ technical lead for the project had some interesting comments on using pair programming. For him, the largest benefits were for the project, not the particular piece of code developers were working on. “The only way to keep everyone marching to the same drumbeat is pairing and rotation. It only works when you have to work with everyone else. I’ve never found any other mechanism for keeping standards on a team.” Everyone was on board with the idea paired programming is about optimizing for the team, not the individual. Reinforcing this point, there are studies pointing to conditions where pairing is less effective, particularly on simple tasks and novice-novice pairing without enough mentoring.

Beyond the general statements about pairing, the team also discussed the best techniques for pairing. One Client dev said, “I found myself doing better where there was only 1 keyboard and we had to pass it back and forth.” They found it’s more engaging when you’re driving. And everyone agreed it is up to the more experienced of the pair to make the other person type.

There is no doubt the confidence of pairing developers is higher than those who work solo. This comes out in a couple ways. First, when giving a daily update on your progress that has been stalled by a bottleneck, it takes the pressure off when you can say, “We’re working on it.” Second, when you’re  in an environment with siloed knowledge, after pairing for a couple days you are willing to say “I’ll try working on that.” On the other hand, if there’s a bottleneck and the key resource is out of the office, the tendency is to look the other way. The devs do not volunteer to help and everyone has to wait for the expert to come back.

The QA lead for the team said he didn’t track the numbers to prove it, but there was a better chance of the story passing a desk check. There is a lower chance of passing the desk check if just one person worked on the functionality.

The conversation went on for a bit more, covering topics such as pair switching, optimizing space and environments, gold plating, and even introduced new ideas like the Ping Pong Pattern. (Did you know using this method in some programming languages may result in switching every 60 seconds?!)

The evening after this meeting I read The Shame of Pair Programming, by Tom Howlett. It’s a great, short read about how bad pairing can be demoralizing. It’s takes both vulnerability and strength. I didn’t see where our team suffered this problem, but it’s something to be watched for. As we talked about in our meeting, it’s not about being an introvert or extrovert, it’s about you. You need to learn how to speak within the pair.

This project was quite the ride. And despite not going live, the closing retrospectives made this one of my favorite projects ever. I feel like I learned more from our ending conversations than on some of my much more successful engagements. Please, continue my learning by adding yours. Add your comments on how paired programming worked for you. This way I, and everyone else, can learn a bit more.


LATE ADDITION (Jan 2020): Here’s a nice post on how to pair by TW dev, Juntao Qiu: 7 Principles of Pair Programming Etiquette.

Be Like Aaron

A colleague of mine died on Friday and the internet is aflame with sorrow and anger. I pray his family sees the outpouring and feels within the lives he touched and love he generated.

Aaron Swartz, a technical prodigy and activist was being prosecuted for allegedly stealing thousands of documents. A quick search will leads you to lots of details about the circumstances around Aaron’s involvement and the justness of Justice in his case.

Aaron and I first met last June and again in November, but I couldn’t say he knew who I was. Our meeting was on a bus and we were part of a rolling conversation covering the the state of business analysis at ThoughtWorks, activism, world affairs, media and branding, privacy, the security apparatus surrounding international travel, and more. In these many topics it was quickly obvious I knew about one or two issues. Aaron knew about everything else. It was intimidating, even more than usual, to be around someone who was so young and obviously better informed than I am.

As many have said, Aaron was a prodigy. And when you read enough, of his own words and those who knew him, you learn his technical abilities were only part of the story. In truth he was much more.

How many times have you wondered how something worked or why something wasn’t just a little better? Aaron wondered that, too. Aaron’s curiosity was childlike, asking why without any pretext or presumption. He understood the problem was with the systems trapping people into a course of action instead of the individuals. He worked to put together all the parts into a coherent whole and the motivation behind that whole. He believed he could work hard and make a change. He believe he, and we, could change the world. And then he worked to make it that way.

Forget about his prodigious skill. Forget about what he built so far. If you can, forget about all we have lost with his passing. Instead, dedicate yourself  to doing what Aaron did. Find a problem. Choose to understand the big picture instead of complaining. And then do something to fix it.

Aaron asked lots of questions, and then he offered himself and his talents to the solution. As we start 2013, I cannot think of a better resolution to make than to be more like Aaron.

Why I Work @ ThoughtWorks – my version

Aaron Erickson is a co-worker I’ve not yet met. As the New Year turned over he wrote a great post, Why I Work At ThoughtWorks (and why you should too…). I do not disagree with anything Aaron wrote, but I want to add some amplification based on some very personal opinions.

Pretty much every company says they care about their employees. I’ve worked in companies that said they cared about me. One of my first jobs was in fast food; they proved they cared by giving me a discount on food & a 2% annual bonus. My next job in fast food gave me even less.

All too often (in almost every case), companies put the employee high on the list of priorities, but not high on the list of investments. I worked for a company that made a profit each and every quarter, but it wasn’t enough. In order to improve company profits, the training budget was cut to ZERO for 3 years in a row!

ThoughtWorks isn’t like that. Here’s how I know.

1. They let me take care of my family. My daughter recently caught E. coli O157:H3. The doctor told me this in the same breath she said, “Your daughter’s kidneys are failing and we cannot help you. We have already called the transport unit to take you to another hospital.” It the kind of thing you watch about on the evening news. It’s fast, it’s serious, it’s every parent’s nightmare. When your family member gets this, and it usually strikes children or the very elderly, it takes weeks to recover.

As a father, there isn’t a choice. You take care of your family. Nothing else is an option. So I sent an email to a few folks, “My daughter’s sick. I’m taking all my vacation and sick time for the year. Effective immediately.” I didn’t put it in nice terms. I was too wrapped up in our family to care about nice.

And the response I got back was, “Do you need anything else?”

ThoughtWorks didn’t say, “What about the stories your team needs?” “Where is the presentation you were going to give to extend our client business?” Or even, “What about the huge project you’ve been working on for 13 months?”

Nope, they offered to bring dinner for my wife and me. They sent a nice gift, immediately. But other than gently asking how my daughter was doing, they let me have my time and space. (post script: My daughter is doing much better now.)

1 (continued). The insurance rocks. I don’t know how much treating a child for four weeks in a children’s hospital costs, but the price has got to be huge. More than I make in many years, even though I’d gladly pay it if I had to. I’d pay anything for my daughter’s life.

When the administrative staff asked for our credit card, the amount was closer to $100 dollars than it was to $500. Read that again. Our bill was far less than $500 because ThoughtWorks offers great insurance. And in a time of crisis, I needed it. You have no idea how grateful my family feels about their foresight.

2. Employees can (and do) lead initiatives. I want to grow the Business Analyst skills at ThoughtWorks. We hire the very brightest candidates, but business analysis has never received the same focus our world-class developers have experienced. I want to change that. So, I talked to some folks and we started working on somethings last year, but clients and projects and life got in the way; it petered out. But this year I’ve picked up the ball and I’m running with it. I didn’t ask anyone for permission. I didn’t beg for time. I just said, “I’m starting this thing over here. I’m doing this action. I’m planning this other event. Let’s make this happen.”

You know what? It’s happening. We’re starting to meet more often as a community. I’m really excited about the upcoming annual meeting where I’m pushing a track of BA topics. I’ve got experts who are planning to fly across the globe to share with us. All because I said, “Let’s make this happen.”

And the official response from ThoughtWorks? “Good job, Jeffrey. Do you need anything else?”

This is not the only example I have where employees take a bit of time and effort and it ends up shifting the company. Don’t you want to work in a place where you can make a difference?

3. We might just change how people work. Seriously, we are starting an initiative I think is revolutionary. It’s got a silly name, but the Continuous Development & Performance has got some real meat behind it. I love this thing so much, I wrote an internal response to it.

Some firms, a few of them, claim to let employees develop a personal career path, but mostly they just abandon their workers to chance. A small number of corporations do a good job of developing their employees, but typically only for a very select minority tapped to be future leaders. Most companies don’t do a damn thing to really help their employees.

This plan—combining encouragement to own your own career AND giving you the tools and opportunity to act AND supporting this with the review process—is unheard of. I don’t know any models for us to follow and it doesn’t sound like anyone else does either.

Wow, what a bold and audacious undertaking!

And with our boldness, stepping into what no one else is doing, I want to offer my own encouragement. If you are an employee reading this and thinking, “What does this mean for my next review?,” then I want you to ask two more questions. Ask yourself, “What have I done to grow professionally?” and “What have I done to help my peers reach their goals?”

For this new plan to take hold and take root, we have to invest our time and effort in more than just a process change. We need to invest in changing ourselves, our people, and our culture. Changes like this take time, small changes can take 1-1/2 years, this could take us 3 years or more. But can you imagine how cool it will be when we achieve this? When all of us are equipped to own our own career development? When every ThoughtWorker is working to grow and help each other grow?

This is big. This can change someone’s life. This is something everyone needs. Not every ThoughtWorker. Everyone. My sister, your cousin, and the kids down the block, figuring out whether to ditch class or not. Everyone can get something from this. This is change that can make a difference not only at ThoughtWorks, but in the world of work.

If we make it work . . . If you figure out how to grow yourself and help others do the same . . . If you embrace this change . . . We can change the world, again.

Jeez, I love this job.

If you want to read the reasons why a technical person should check out ThoughtWorks, then read Aaron’s post. And if you care about equality, using technology to help social problems, and positively impacting society and community for future generations, then check out ThoughtWorks’ website.

Join ThoughtWorks

And if you’re someone who wants to work for a transnational employer that knows how to care for you, then checkout It’s not easy to get hired here and the job isn’t for everyone, but I struggle to think of a company that’s better.

Jeez, I love this job.