How to get remote workers to properly engage while working on a task together?

Question

I believe pair programming creates MUCH cleaner code, much less bugs, better reusable architecture, and better team culture/bond. At my old job, I created dozens of pair programming setups in a traditionally "cubicled" culture. Those programmers ended out outperforming their peers on other projects by miles.

When I started my own company I started facing the following problem: offshore programmers are very shy. I've had a few programmers quit in the middle of an interview because they were too shy to let me see them code. However their GitHub profiles were great.

The second problem comes when pair programming online, it never seems to catch on as well as in a physical team room. Generally I've found the other programmer just sits around checking email or doing their own thing. There is very little conversation/interaction. This removes the benefits of working collaboratively.

Currently, I set up the programmers in a Google Hangouts session and give them one of 3 tasks

• Solve a bug
• Solve an architectural issue
• Train employee in architecture

How can I encourage or facilitate employees to better engage when working collaboratively but in an online/remote work environment?

Answer 1

As a software developer, if you asked me to collaborate over a hangout session I'd send you the text outlined below to explain why I'm not engaging, wait for the call to end, divide up the labor with my partner, each do half, and get paid to work part time until the next critical event. The solution to this is to present compelling objective argument for why they should work together and engage team-members in determining the most effective software development methodology for their work environment.

Last week Kent Beck made a claim that you don't really need bug tracking databases when you're doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs. That didn't sound right to me. I looked in our own bug tracking database here at Fog Creek to see what kinds of bugs were keeping it busy.

Lo and behold, I discovered that very few of the bugs in there would have been discovered with pair programming or test driven development. Many of our "bugs" are really what XP calls stories -- basically, just feature requests. We're using the bug tracking system as a way of remembering, prioritizing, and managing all the little improvements and big features we want to implement.

A lot of the other bugs were only discovered after much use in the field. The Polish keyboard thing. There's no way pair programming was going to find that. And logical mistakes that never occurred to us in the way that different features work together. The larger and more complex a program, the more interactions between the features that you don't think about. A particular unlikely sequence of characters ({${?, if you must know) that confuses the lexer. Some ftp servers produce an error when you delete a file that doesn't exist (our ftp server does not complain so this never occurred to us.)

I carefully studied every bug. Out of 106 bugs we fixed for the service pack release of CityDesk, exactly 5 of them could have been prevented through pair programming or test driven design. We actually had more bugs that we knew about and thought weren't important (only to be corrected by our customers!) than bugs that could have been caught by XP methods.

http://www.joelonsoftware.com/articles/FiveWorlds.html

For example, pair programming (a typically YAGNI development type process), in which each software task has a pair of developers allocated to it, reduces the risks of staff turnover or absences. However, there is an apparent reduction in productivity, as each task now requires two people.

http://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf

Answer 2

Not much has changed in four years in our field. I think part of the sentiment that my colleague with the answer was sharing may be due to the fact that the business actors in our field (CTOs, Human Resources, CEOs) have expropriated pair programming as a way to "test" someone's skill level during a job interview, as if looking for work and interviewing wasn't stressful, now you have a colleague whom you've never met, making a judgment call about your skill level and the assumption in the in-human resources paradigm is that if the person has the job and you are the shmo looking for the job, then they know more than you, which may or may not be the case, either way it flies in the face of what the whole purpose and original intent of pair programming is for.

I’m a huge advocate of pair programming as a way of bringing a kind of mutual accountability to the learning experience of new software developers, the way the business world has been using pair programming in interviews flies in the face of mutual accountability and the original intent of pair programming which was for colleagues to help each other out. The original intent of the pair programming idea is to learn collaboratively by doing remote pair programming, which speaks to what you are talking about in your OP, but many of us have been on the receiving end of what I just described the business world has used pair programming for, just another tool to toss more resumes into the file cabinet marked as rubbish and so when you get backlash answers like the one my colleague gave four years ago, do not be surprised by them.

Certain schools of thought would say what is wrong with using pair programming as part of an interview process. Right, so the idea as I understand is that it should be no different than a couple of pilots on an airliner jumping into a simulator and working together, well, any pilots in the room? You are now in a cabin with a complete stranger, so that makes you nervous enough, right? It does for me. You are not working "together" in this simulation but rather you are being judged for passing this simulator test by the other guy who is in the cabin with you, so that sets a different kind of tone then what I argue was the original intent of pair programming. So there is your problem, you are not seeing that candidate at their best and as one keen company recently posted in one of their job ads, we want to see you at your best.

Answer 3

I get that you like pair programming, but understand a lot of developers don't. Most of them, in fact. (I would instantly quit if told that I had to have someone looking over my shoulder all day). Additionally, part of the benefit of being a remote worker is flexibility in scheduling, which you're taking away from them with this idea. So you may want to rethink this idea. Its one thing to work together on a specific short term issue, especially if the one not doing the main work is the expert in that area. Its another to expect it to be the norm.

I'd also dispute the idea of pair programming actually creating value (I don't see it finding more bugs than code review but takes significantly more resources and greatly decreases employee enjoyment of work and morale, and generally decreases speed of even a single programmer working alone). But my guess is we're not going to agree on that.

Answer 4

I think the challenge is to create that collaborative working environment. You have to find people willing to engage in and embrace pair programming. You may be bumping into some cultural elements here as well.

You can make remote pair programming work, but you need more than just HipChat. You need a fully collaborative pairing environment. One place I worked used AWS servers and applications that allowed both programmers to control the editor at the same time. This type of collaborative tooling is critical and my experience is just one example. You have to simulate the shared keyboard experience.

As to the programming interviewees that flee when you want to see code. They were lying about their github profiles and more than likely knew you would see through their deception I am guessing.