Pair Programming is a technique that puts two developers in front of one computer in order to solve a programming task collaboratively. Currently, I'm constantly pairing up with a co-worker in order to find more simple solutions to complex problems and to spread knowledge between us. We each know some of our team's systems but barely know the systems on which the other is working. So far, so good.
A much more interesting aspect is that we have very different backgrounds. He's a trained software developer (three years of professional training) and used to work for a company that didn't value aspects like testing, maintainability, and code quality much. Instead, they simply shipped a lot of stuff - mostly smaller client projects. In contrast to this, I studied Computer Science at a renowned university, and - in parallel - worked for several different companies as a student developer, often on larger systems. Therefore, I've seen many different takes on the aforementioned coding aspects and have experienced - and committed - many "textbook pitfalls" myself. I learned from each of them, and I had the luxury of learning from a diverse set of co-workers and instructors.
From the previous paragraph, I hope it has become clear that both of us have very different backgrounds, their own share of experience, and quite different views on professional development. From this stems a very strong conflict potential. These conflicts are not personal in nature, but revolve arount testing methodology and coding style: How to name tests? How to structure them? How to cut our system into functions and methods? How small should they be? When to stop building abstractions to avoid overengineering? What to document and where? In quite some aspects, I possess more and more relevant exprience but he often has good arguments coming from his own experience. Therefore, whe often find ourselves learning a lot from each other. We also kind-of enjoy our "nerdy disputes", but they drain our energy reserves significantly, which is starting to affect our work.
Maybe some of you spent a significant time pair programming in their career? If so, how did you handle conflict-prone pairings like this? I'd really like this programming task to not only yield a good piece of software. I'd also really like to learn about managing professional conflicts such as these, where there's often no clear right or wrong solution.