Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've recently started at a new job and pairing has helped me become effective there very quickly. I am, however, having a hard time when we must do brief joint research during our workflow, covering API features, code examples, or command options. My team lead urges us to do all research on our pairing station, rather than our individual laptops, and to synchronize our research by verbally negotiating the steps between different web resources.

I research, read, and absorb information differently from my pairing partner, and I feel much more productive when I can follow a thread of research to the next web page exactly when I want to, rather than trying to keep exact pace and place with what my partner's reading. We're both smart and fast, but we can't help moving in different ways and instantaneous velocities when we're figuring stuff out. It seems so much easier to poke around individually for a minute until one of us says "I've got it," then get back together and code.

When you pair program, how do you handle short research tasks? What works best for you, and how to you keep in sync with your partner?

share|improve this question
add comment

3 Answers 3

Pair programming is a tool. Like any tool, there are times when it's useful and times when it's not. Using the right tools for the job can involve different tools at different times, including a mixture of those tools.

Thus, if the situation calls for it, break away when necessary and meet back up when necessary.

For instance, if you both are researching something and one of you finds something interesting, then maybe you both can look at it together. But if you're both trying to find an answer, sometimes breaking apart to search in parallel is more productive.

When one of you finds the answer, resume the pair programming session.

In short, it's called Pair Programming, not Pair Researching.

share|improve this answer
add comment

When I pair program whoever is not typing at the main computer has access to a laptop to do research. This makes the whole process less frustrating for the 'non-typing' member of the pair.

share|improve this answer
1  
Isn't the non-typer then distracted from what the pair's trying to accomplish? How does he or she catch up on what the other programmer accomplished while they weren't looking? –  Anna Lear Feb 12 '11 at 6:02
2  
If two people are working on two computers, that is not pair programming! –  Johnsyweb Feb 12 '11 at 6:38
6  
If the person at the pair programming station is researching and not programming, then the catching up process simply involves a "Hey dude! Check out what I just found...". Just because both people are researching something independently doesn't mean they stop communicating. –  jmort253 Feb 12 '11 at 7:53
    
I don't think I want to go this far - when code's being written, I want to be looking at it. I'm talking more about the situation where we both know what we have to do next, but we don't know how to do it - so we take a minute to look it up. –  traffichazard Feb 12 '11 at 14:53
2  
To clarify my answer. The non-typing member would generally only be doing research if code was not being written at that time. For example the typing member is building or researching too. @Johnsyweb I think it is important to recognize that pair programming (or anthing for that matter) is not an all or nothing proposition. –  westcoastdiff Feb 12 '11 at 19:41
add comment

Parallel research is very powerful if you are looking for answers in different locations. "You read that article, I'll browse the book and we'll sync back in 10 minutes". Whoever comes up with a (possible) solution should share the knowledge of course.

One great way to handle this is by using a "spike". This happens during the estimation meeting to help make the estimates more accurate. In short, you postpone estimation of a specific task until the (timeboxed) spike is complete and you know enough about the problem to confidently put a number on it. This may include trying out some new lib or component or write a small program as a proof-of-concept.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.