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.
Top comments (6)
How to do pair-programming - or pull-request reviews - well is a hard question, not a technical one, and there is no shortcut.
You have to replace contempt by curiosity, learn to listen - which means mostly learn to shut up, forget about being right or wrong, learn compassion, learn to see things from the perspective of the other, and learn the subtle art of not giving a fuck to things that don't matter really much, because There Are More Than One Way To Do It(TM)
You will make mistakes along the way, only bad people never make mistakes because they never recognize the ones that they did.
You could start by having both of you read and discuss this article:
How to use a code review to execute someones' soul
Thank you for your input! :) I don't think we encountered much contempt, but more curiosity never hurt anyone. Except for cats. Also, that article is a really good one - it's a re-(re-re-)read for me, and I'll propose it to my colleague. :)
You need a style guide and clearly don't have one.
These conversations should be done over time, and when a resolution and middle ground for the entire COMPANY not just you two, is found, it should be added to the guide. Whether or not you agree with all the things in the guide is irrelevant once they are discussed and put in (voting system, general agreement, whatever you have).
There are pre-built styleguides for all languages out there which can get you started, and also help you find best practices. You can fork these usually, and then add on the pieces you find missing. Agree to meet once a week to expand the guide, add to the guide ANYTIME a resolution is found, and eventually you will taper off your meetings because these things are documented.
Without a style guide, I guarantee every programmer in that office is driving every other programmer a little crazy with their individual ideas on how things should be written.
Never forget, programming is first ART and second LOGIC. You are telling a computer what to do, but there are an infinite number of ways to go about doing that, and there will always be more. You are not picking the one-true-way, or the right way, you are simply picking A way.
One last thing, you should allow others to fail after giving them a suggestion. Perhaps even you are wrong (if we always knew when we were wrong, we'd be liars instead of simply wrong). Failure is not bad unless it stops your paycheck from coming in! Simple programming misunderstandings or ideas do not make a project fail or lose your job 99.9% of the time
I just found out that we do have one in our company, and it's very widely agreed upon. However, now that I've had two more days to think about this, I think we need to agree upon an architectural style for the software we're writing.
Regarding the suggest-and-let-fail part: This is something I actively try to do already. I can't figure out if it bothers him more than telling him "I think this won't cover all cases because X".
I find that when I come against issues like those that my first instinct is to define things and set standards. It does mean that you have to stop and decide something right now, but it means that when these things are done in the future then you will have consistency.
This pair-programming endeavour of ours is actually starting to set something like this into motion in our team. :) It's the first time we do this so deliberately, we as a team are already learning and adapting things.