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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.