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

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
1
down vote

favorite

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.

edited Apr 13 '17 at 12:48

Communityâ™¦

asked Apr 10 '15 at 1:43

Adrian773

7571611

Consider editting the question to make it more general workplace related. Technical jargon clouds the general issue of "Maintaining mentorship with a mentor who has a different problem solving style".
â€“Â Myles
Apr 10 '15 at 14:26

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me <-- I don't understand this conflict. If the solution is only to be used by you, why does your senior's input matter? OTOH, if it was for a product to be used by others, then your senior's input cannot be ignored, even if it is "wrong".
â€“Â Brandin
Apr 10 '15 at 15:46

@Myles Done, some of the technical jargon is unavoidable but I generalized the question in an appropriate way I think.
â€“Â Adrian773
Apr 12 '15 at 20:50

@Brandin I edited the question to show that this developer is not "my" senior/boss. Also that particular example originated because I went to him to ask "how" to implement something since I knew he had almost certainly already done the same thing for a different purpose and he suggested using a database instead.
â€“Â Adrian773
Apr 12 '15 at 20:58

@Adrian773 If he's not your boss then it's ultimately up to you whether you used a database in that circumstance. The situation sounds to me like You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. This is not a "conflict" unless you try and argue the point (for no reason). It's just two different opinions. If you want to do X, just do it. You don't even have to mention it to him.
â€“Â Brandin
Apr 12 '15 at 21:15

Â |Â
show 2 more comments

up vote
1
down vote

favorite

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.

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 2: I changed the question and removed a lot of the technical detail as per suggestion in comments.

edited Apr 13 '17 at 12:48

Communityâ™¦

asked Apr 10 '15 at 1:43

Adrian773

7571611

Consider editting the question to make it more general workplace related. Technical jargon clouds the general issue of "Maintaining mentorship with a mentor who has a different problem solving style".
â€“Â Myles
Apr 10 '15 at 14:26

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me <-- I don't understand this conflict. If the solution is only to be used by you, why does your senior's input matter? OTOH, if it was for a product to be used by others, then your senior's input cannot be ignored, even if it is "wrong".
â€“Â Brandin
Apr 10 '15 at 15:46

@Myles Done, some of the technical jargon is unavoidable but I generalized the question in an appropriate way I think.
â€“Â Adrian773
Apr 12 '15 at 20:50

@Brandin I edited the question to show that this developer is not "my" senior/boss. Also that particular example originated because I went to him to ask "how" to implement something since I knew he had almost certainly already done the same thing for a different purpose and he suggested using a database instead.
â€“Â Adrian773
Apr 12 '15 at 20:58

@Adrian773 If he's not your boss then it's ultimately up to you whether you used a database in that circumstance. The situation sounds to me like You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. This is not a "conflict" unless you try and argue the point (for no reason). It's just two different opinions. If you want to do X, just do it. You don't even have to mention it to him.
â€“Â Brandin
Apr 12 '15 at 21:15

Â |Â
show 2 more comments

up vote
1
down vote

favorite

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.

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 2: I changed the question and removed a lot of the technical detail as per suggestion in comments.

edited Apr 13 '17 at 12:48

Communityâ™¦

asked Apr 10 '15 at 1:43

Adrian773

7571611

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.

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 2: I changed the question and removed a lot of the technical detail as per suggestion in comments.

edited Apr 13 '17 at 12:48

Communityâ™¦

asked Apr 10 '15 at 1:43

Adrian773

7571611

edited Apr 13 '17 at 12:48

Communityâ™¦

edited Apr 13 '17 at 12:48

Communityâ™¦

edited Apr 13 '17 at 12:48

Communityâ™¦

asked Apr 10 '15 at 1:43

Adrian773

7571611

asked Apr 10 '15 at 1:43

Adrian773

7571611

asked Apr 10 '15 at 1:43

Adrian773

7571611

Consider editting the question to make it more general workplace related. Technical jargon clouds the general issue of "Maintaining mentorship with a mentor who has a different problem solving style".
â€“Â Myles
Apr 10 '15 at 14:26

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me <-- I don't understand this conflict. If the solution is only to be used by you, why does your senior's input matter? OTOH, if it was for a product to be used by others, then your senior's input cannot be ignored, even if it is "wrong".
â€“Â Brandin
Apr 10 '15 at 15:46

@Myles Done, some of the technical jargon is unavoidable but I generalized the question in an appropriate way I think.
â€“Â Adrian773
Apr 12 '15 at 20:50

@Brandin I edited the question to show that this developer is not "my" senior/boss. Also that particular example originated because I went to him to ask "how" to implement something since I knew he had almost certainly already done the same thing for a different purpose and he suggested using a database instead.
â€“Â Adrian773
Apr 12 '15 at 20:58

@Adrian773 If he's not your boss then it's ultimately up to you whether you used a database in that circumstance. The situation sounds to me like You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. This is not a "conflict" unless you try and argue the point (for no reason). It's just two different opinions. If you want to do X, just do it. You don't even have to mention it to him.
â€“Â Brandin
Apr 12 '15 at 21:15

Â |Â
show 2 more comments

Consider editting the question to make it more general workplace related. Technical jargon clouds the general issue of "Maintaining mentorship with a mentor who has a different problem solving style".
â€“Â Myles
Apr 10 '15 at 14:26

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me <-- I don't understand this conflict. If the solution is only to be used by you, why does your senior's input matter? OTOH, if it was for a product to be used by others, then your senior's input cannot be ignored, even if it is "wrong".
â€“Â Brandin
Apr 10 '15 at 15:46

@Myles Done, some of the technical jargon is unavoidable but I generalized the question in an appropriate way I think.
â€“Â Adrian773
Apr 12 '15 at 20:50

@Brandin I edited the question to show that this developer is not "my" senior/boss. Also that particular example originated because I went to him to ask "how" to implement something since I knew he had almost certainly already done the same thing for a different purpose and he suggested using a database instead.
â€“Â Adrian773
Apr 12 '15 at 20:58

@Adrian773 If he's not your boss then it's ultimately up to you whether you used a database in that circumstance. The situation sounds to me like You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. This is not a "conflict" unless you try and argue the point (for no reason). It's just two different opinions. If you want to do X, just do it. You don't even have to mention it to him.
â€“Â Brandin
Apr 12 '15 at 21:15

Consider editting the question to make it more general workplace related. Technical jargon clouds the general issue of "Maintaining mentorship with a mentor who has a different problem solving style".
â€“Â Myles
Apr 10 '15 at 14:26

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me

<-- I don't understand this conflict. If the solution is only to be used by you, why does your senior's input matter? OTOH, if it was for a product to be used by others, then your senior's input cannot be ignored, even if it is "wrong".
â€“Â Brandin
Apr 10 '15 at 15:46

Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me

@Myles Done, some of the technical jargon is unavoidable but I generalized the question in an appropriate way I think.
â€“Â Adrian773
Apr 12 '15 at 20:50

@Brandin I edited the question to show that this developer is not "my" senior/boss. Also that particular example originated because I went to him to ask "how" to implement something since I knew he had almost certainly already done the same thing for a different purpose and he suggested using a database instead.
â€“Â Adrian773
Apr 12 '15 at 20:58

@Adrian773 If he's not your boss then it's ultimately up to you whether you used a database in that circumstance. The situation sounds to me like You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. This is not a "conflict" unless you try and argue the point (for no reason). It's just two different opinions. If you want to do X, just do it. You don't even have to mention it to him.
â€“Â Brandin
Apr 12 '15 at 21:15

Â |Â
show 2 more comments

4 Answers
4

active

oldest

votes

up vote
8
down vote

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.

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

suggest improvementsÂ |Â

up vote
3
down vote

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.

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

suggest improvementsÂ |Â

up vote
2
down vote

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).

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

suggest improvementsÂ |Â

up vote
2
down vote

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.

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

suggest improvementsÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f43924%2fmaintaining-mentorship-with-a-mentor-who-has-a-different-problem-solving-style%23new-answer', 'question_page');

);

Post as a guest

Name

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();

);
);

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

up vote
8
down vote

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.

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

suggest improvementsÂ |Â

up vote
8
down vote

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.

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

suggest improvementsÂ |Â

up vote
8
down vote

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.

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

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.

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

answered Apr 10 '15 at 3:40

keshlam

41.5k1267144

suggest improvementsÂ |Â

up vote
3
down vote

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.

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

suggest improvementsÂ |Â

up vote
3
down vote

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.

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

suggest improvementsÂ |Â

up vote
3
down vote

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.

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

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.

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

answered Apr 10 '15 at 9:31

nvoigt

42.6k18105147

suggest improvementsÂ |Â

up vote
2
down vote

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).

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

suggest improvementsÂ |Â

up vote
2
down vote

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).

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

suggest improvementsÂ |Â

up vote
2
down vote

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).

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

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).

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

edited Apr 10 '15 at 4:02

answered Apr 10 '15 at 2:01

samarasa

1,90621430

answered Apr 10 '15 at 2:01

samarasa

1,90621430

answered Apr 10 '15 at 2:01

samarasa

1,90621430

suggest improvementsÂ |Â

up vote
2
down vote

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

suggest improvementsÂ |Â

up vote
2
down vote

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

suggest improvementsÂ |Â

up vote
2
down vote

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

answered Apr 23 '15 at 14:44

Jay Godse

1,290710

suggest improvementsÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky