speed. The senior member may become unhappy and it may be an ineffective use of their time. While the levels of experience should be similar, the areas of expertise can vary (e.g., one can be more skilled in data engineering while the other is more experienced in workflow). Therefore, consider who the peers really are (e.g. those at or near the same professional level of experience) and pair them appropriately.
Working as a pair: Many programmers simply work better in isolation. They like to review the requirement or defect and individually derive the best programming solution per their skill level. Then they like to code as and when they want to code without restraint of another's schedule or work hours. In pair programming, the two programmers work together constantly and will be assessing each other's deliverables continuously. This means they must work roughly the same hours and agree to the working process. Most importantly the pair must enjoy each other's company, have similar personalities, have flexible egos, and be constantly open minded of each other's ideas and opinions. Otherwise, this working relationship can be frustrating to one of both of the pair.
Focusing on problem-solving work: Pair programming is not for all types of programming work. For example, it may be an ineffective use for maintenance or routine enhancement work. For this type of work, applying a peer review (e.g., code review) at regular intervals may be more efficient. When initiating a pair programming program, identify the better types of work that can make pair programming a success like "release 1" of a product that requires considerable problem solving (in design and coding), or projects that have challenging defects to resolve, or work that requires getting into the flow or zone while also requiring documentation (one member of the pair can keep in the zone while the other does the documentation).