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".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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".