That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two o

That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it. A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming. After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality. Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.