Maintaining mentorship with a mentor who has a different problem solving style

Question

Background: I'm a recent degree graduate and software developer. The company I work at has a relatively small team with 8 members. I'm the newest on the team and have been here 10 months.

I get along well with one of the senior developers whenever I'm talking about anything other than code specifics. I need to go to him for support frequently since he knows .NET quite well. When we are talking about the different ways of solving a technical problem I'm having trouble with there is noticable conflict and tension. This is because we both have different ways of doing things and a different fundamental thought proccess. Just one example (of many) where we think differently is that I was trained with more focus on object oriented design, using inheritance whereas he sees data by the way it would fit into a table and even questions why you would use inheritance versus just a plain reference to a parent object.

Whenever I try to politely say something along the lines of "I see your point, but I still think this is the better approach because x y z" he doesn't see my point of view and even gets a little bit more insistent that the method he is recomending is better and this causes increased tension. I do understand where he is coming from and I can see the benefits of doing it his way, however I see more benefits from solving the problem my way.

So, my question is how do I deal with him in a way that would see my relations with him improving or is the best approach to simply enforce some space between him and me when it comes to technical conversations and as a result inhibiting him becoming a valuable mentor?

NOTE: How can I reduce communication gaps with a colleague who has different working style? <-- A similar question but more about communication which is not an issue.

EDIT: This person is not my superior, he is simply a more experienced colleague, the boss of mine (I have 2...) that is in charge of my work works and thinks the same way as me when it comes to solving problems. This means that implementing a solution in the way this other developer is suggesting would result in me having to have the same discussion with my boss but me arguing for an implementation I don't really believe in. My boss doesn't know .NET very well however so he is unable to assist with the technical/implementation questions I have.

EDIT 2: I changed the question and removed a lot of the technical detail as per suggestion in comments.

Answer 1

Your determination to use OOP where it may not matter, and his determination to use a real database where it may not matter, are flip sides of the same coin. You'll get along with him better if you remember that this is a craft, not a science, and two developers will often approach the same problem from different directions without either being wrong. Picking the best solution depends on how it's going to be used, and on how much effort it'll take one way or the other... and that last varies from individual to individual. And sometimes the right answer isn't the one that's best technically OR that you prefer, but the one that'll be easier to maintain.

Rather than getting caught up in who's right, focus on learning why a suggestion is being made and what the trade-offs are.

And if at all possible, don't fight over things that don't matter. Who's right matters less than getting the job done.

Answer 2

I see your point, but I still think this is the better approach

"Better" in this sentence is a purely fictional measurement, at least to him. You (both, as a team) have never set the standards of "good" so assuming something is "better" has no common base.

You have been taught that OOP is "better". But if it was a good education, you have also been taught why. So make a case. What would your solution offer that his would not offer. What could be done with your software, that could not be done with his?

If you present him with a likely business case that your solution would handle in less time or for less money, then he will see that it is indeed "better". If you cannot come up with an example why your approach is "better", maybe it's not. OOP and Inheritance are tools to solve problems. Maybe this is not the right problem for the toolset you have? It could as well be that you need a second (and third and fourth...) toolset.

Answer 3

I would like to suggest you to start the conversation with him in a positive mindset -- e.g., I might learn great things from this senior developer etc. Why don't want you to know why his method is better than yours by asking several questions on his method.

I think that it would be good to remember some relevant "Dale Carnegie's rules" here:

1) Don’t criticize, condemn or complain (without trying a right approach -- I believe the above one that I mentioned is one of them);

2) Arouse in the other person an eager want (make him to think that he is also contributing to your project/solution).

Answer 4

If your OOP approach is better, present a couple of use-cases in your situation where the OOP approach works better than the database/table approach (which looks like delegation). If the use-cases are important enough, it may help your mentor arrive at your conclusion.

Since he's the mentor, it might also behoove you to try his approach end-to-end. You may learn that his way is better, or that your way is better, or that both ways are just 2 different ways of solving the same problem. But your knowledge will be experience-based. And if you learn both ways, then the next time you ask him for help, you'll be able to translate his preferred approach to your preferred approach without difficulty.

I had a situation where I wrote a chunk of code using the Ruby Enumerable library with cascading map/reduce blocks to do a painful data processing job on a data set. My boss didn't appreciate the benefits of using cascading map/reduce (a more functional style of programming), and complained that the code was hard to read. I countered by saying that if he could write the code more concisely using a more imperative coding style, then I would switch. (I only said it because I knew that previous attempts at similar problems had triple the code volume, and it was brittle). My approach has stood so far because it works, and because he has not yet produced code to solve the same problem in the imperative programming style. In this case, I have tried the two different methods, so I was able to both articulate the differences, and write the code. Knowing both methods and the pros and cons raises your credibility.