20

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?

traffichazard
  • 301

3 Answers3

14

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.

jmort253
  • 9,347
8

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.

westcoastdiff
  • 81
3

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.

Martin Wickman
  • 13,365