One of my first full time dev jobs regularly used pair programming, but primarily as a mentoring tool. Essentially the junior would talk through a new feature or bug report one on one with a senior, and decide on required changes, then observe the senior implementing those changes, asking questions and occasionally–ideally–making suggestions. After a couple weeks they would switch and the junior would “drive”, with the mentor mainly answering questions and making suggestions only when they observed the junior heading down a questionable path. However, the idea was that after a certain amount of time, the junior would “graduate” and start working solo, until they themselves were in a position to act as a mentor. So, obviously this was mainly a tool for “leveling” up juniors who often were not expected to have much if any experience with the framework (Rails) as efficiently as possible.
This job description makes it sound like pairing has a more fundamental role there, although I expect in principle it works the same, albeit with more role switching. I think the benefits are obvious. Two heads are better than one, right? And even experienced devs can occasionally misjudge, misinterpret, or plainly not know the best solution for a given problem. Hell, even in the mentoring model juniors would occasionally come up with great ideas the seniors didn’t, and you just can’t get the same benefit of that kind of mind-sharing with CR alone. The only disadvantage of pair programming in my mind is the resource cost. I really enjoyed my experience with it and honestly this would be a big draw for me if I was in the market for a new FT position.
