Conflict of knowledge with a colleague

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





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







up vote
8
down vote

favorite












An experienced (but in no way senior) developer has joined the same project as myself.



He seems to know vastly more about the programming language we use, but on the other hand I feel I know more about our client, how to deal with clients in general, and importantly how the established applications as well as processes work.



Repeatedly I've tried to convey some of my knowledge to my colleague, but it's getting frustrating. I've noticed a pattern. It feels like I'm having to take far longer to convince him of something (e.g. pointing out potential issues in his plans to upgrade an IDE) than I should do, and would do with others. He then seems to suddenly realise what I'm saying and accept it. Five minutes later he returns with his old approach seemingly ignorant of our previous conversation.



Neither of us has a higher grade than the other, and I like this guy as an aquintance and a colleague, but as I've said sharing knowledge with him is becoming tedious.



How can I go about improving my knowledge sharing with him? I wouldn't say I'm a great communicator to begin with, but I can tell how difficult it is to get something across to him.



What can I do?







share|improve this question
















  • 3




    You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
    – user10911
    Jan 17 '14 at 0:28










  • @geekrunnings I've seen the name of that book batted about, I might look into it.
    – Pureferret
    Jan 17 '14 at 0:31






  • 2




    @Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
    – jmac
    Jan 17 '14 at 0:43






  • 1




    I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
    – Meredith Poor
    Jan 17 '14 at 2:49






  • 2




    Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
    – SpYk3HH
    Jan 17 '14 at 17:25
















up vote
8
down vote

favorite












An experienced (but in no way senior) developer has joined the same project as myself.



He seems to know vastly more about the programming language we use, but on the other hand I feel I know more about our client, how to deal with clients in general, and importantly how the established applications as well as processes work.



Repeatedly I've tried to convey some of my knowledge to my colleague, but it's getting frustrating. I've noticed a pattern. It feels like I'm having to take far longer to convince him of something (e.g. pointing out potential issues in his plans to upgrade an IDE) than I should do, and would do with others. He then seems to suddenly realise what I'm saying and accept it. Five minutes later he returns with his old approach seemingly ignorant of our previous conversation.



Neither of us has a higher grade than the other, and I like this guy as an aquintance and a colleague, but as I've said sharing knowledge with him is becoming tedious.



How can I go about improving my knowledge sharing with him? I wouldn't say I'm a great communicator to begin with, but I can tell how difficult it is to get something across to him.



What can I do?







share|improve this question
















  • 3




    You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
    – user10911
    Jan 17 '14 at 0:28










  • @geekrunnings I've seen the name of that book batted about, I might look into it.
    – Pureferret
    Jan 17 '14 at 0:31






  • 2




    @Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
    – jmac
    Jan 17 '14 at 0:43






  • 1




    I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
    – Meredith Poor
    Jan 17 '14 at 2:49






  • 2




    Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
    – SpYk3HH
    Jan 17 '14 at 17:25












up vote
8
down vote

favorite









up vote
8
down vote

favorite











An experienced (but in no way senior) developer has joined the same project as myself.



He seems to know vastly more about the programming language we use, but on the other hand I feel I know more about our client, how to deal with clients in general, and importantly how the established applications as well as processes work.



Repeatedly I've tried to convey some of my knowledge to my colleague, but it's getting frustrating. I've noticed a pattern. It feels like I'm having to take far longer to convince him of something (e.g. pointing out potential issues in his plans to upgrade an IDE) than I should do, and would do with others. He then seems to suddenly realise what I'm saying and accept it. Five minutes later he returns with his old approach seemingly ignorant of our previous conversation.



Neither of us has a higher grade than the other, and I like this guy as an aquintance and a colleague, but as I've said sharing knowledge with him is becoming tedious.



How can I go about improving my knowledge sharing with him? I wouldn't say I'm a great communicator to begin with, but I can tell how difficult it is to get something across to him.



What can I do?







share|improve this question












An experienced (but in no way senior) developer has joined the same project as myself.



He seems to know vastly more about the programming language we use, but on the other hand I feel I know more about our client, how to deal with clients in general, and importantly how the established applications as well as processes work.



Repeatedly I've tried to convey some of my knowledge to my colleague, but it's getting frustrating. I've noticed a pattern. It feels like I'm having to take far longer to convince him of something (e.g. pointing out potential issues in his plans to upgrade an IDE) than I should do, and would do with others. He then seems to suddenly realise what I'm saying and accept it. Five minutes later he returns with his old approach seemingly ignorant of our previous conversation.



Neither of us has a higher grade than the other, and I like this guy as an aquintance and a colleague, but as I've said sharing knowledge with him is becoming tedious.



How can I go about improving my knowledge sharing with him? I wouldn't say I'm a great communicator to begin with, but I can tell how difficult it is to get something across to him.



What can I do?









share|improve this question











share|improve this question




share|improve this question










asked Jan 17 '14 at 0:04









Pureferret

156310




156310







  • 3




    You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
    – user10911
    Jan 17 '14 at 0:28










  • @geekrunnings I've seen the name of that book batted about, I might look into it.
    – Pureferret
    Jan 17 '14 at 0:31






  • 2




    @Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
    – jmac
    Jan 17 '14 at 0:43






  • 1




    I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
    – Meredith Poor
    Jan 17 '14 at 2:49






  • 2




    Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
    – SpYk3HH
    Jan 17 '14 at 17:25












  • 3




    You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
    – user10911
    Jan 17 '14 at 0:28










  • @geekrunnings I've seen the name of that book batted about, I might look into it.
    – Pureferret
    Jan 17 '14 at 0:31






  • 2




    @Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
    – jmac
    Jan 17 '14 at 0:43






  • 1




    I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
    – Meredith Poor
    Jan 17 '14 at 2:49






  • 2




    Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
    – SpYk3HH
    Jan 17 '14 at 17:25







3




3




You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
– user10911
Jan 17 '14 at 0:28




You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
– user10911
Jan 17 '14 at 0:28












@geekrunnings I've seen the name of that book batted about, I might look into it.
– Pureferret
Jan 17 '14 at 0:31




@geekrunnings I've seen the name of that book batted about, I might look into it.
– Pureferret
Jan 17 '14 at 0:31




2




2




@Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
– jmac
Jan 17 '14 at 0:43




@Pure, the book is from the 1920's and has fallen out of copyright so you can read it for free online. Just for reference.
– jmac
Jan 17 '14 at 0:43




1




1




I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
– Meredith Poor
Jan 17 '14 at 2:49




I'm not really sure the book referenced above has much to do with this situation. My take on that book (which I recall reading in the 1970s) was that people enter life with self-centered mindsets and all one really has to do is learn to 'meet in the middle' and develop a certain amount of empathy. I spend a lot of time around a few people that 'know it all' and get flummoxed if your perspective is different. They're always in 'lawyer mode' which is 'yes but...'.
– Meredith Poor
Jan 17 '14 at 2:49




2




2




Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
– SpYk3HH
Jan 17 '14 at 17:25




Another consideration, Do you think he might be in the ASD? If so, then this becomes a whole nother issue entirely. Having Autism of any degree makes expression of emotion or understanding of environmental stimulus quite hard. I live with it from my wife and child everyday, and I can promise you, at even a mild form (like my wife) it can be quite frustrating, but patience tends to be key.
– SpYk3HH
Jan 17 '14 at 17:25










4 Answers
4






active

oldest

votes

















up vote
9
down vote



accepted










You can stop creating problems (this IDE upgrade isn't going to work!) and start fixing problems (that new IDE won't support my stuff, and swapping IDEs is a pain. How about X?).



Because at the face of it, it sounds as your colleague doesn't respect you. Especially among developers, respect comes with your ability to solve problems. As soon as you start creating impediments or not offering solutions you get lumped in with management, marketing, and customers; not a peer to work with.



I might be wrong, and this is a guess. In the end, to share knowledge more effectively you'll need to get your colleague to value your knowledge. Sometimes that means having better knowledge, sometimes it's showing how that knowledge is valuable, sometimes it means making the nuance of the knowledge more understandable... But if they don't value what you're selling, they'll tune you out.






share|improve this answer




















  • Absolutely agree. I hope that's what happened in my case.
    – superM
    Jan 17 '14 at 14:53






  • 5




    Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
    – SpYk3HH
    Jan 17 '14 at 15:26

















up vote
1
down vote













when i see this happening instead of proxying for the client (pointing out potential issues on the clients behalf) i say to the person involved "oh, you might want to check in with X before you do that" where X is someone with more authority and will likely block the move. That way you don't waste time talking to a brick wall, also over time your colleague might develop a mental checklist of potential client impacts from any desired changes (sounds like this checklist is simply not present at the moment).



if they don't listen to you and don't "check in with X" (X being senior) then likely a spot of bother will ensue and you can watch them as they work to mop up the spill. Enough spills and eventually they might just start to listen to you.






share|improve this answer



























    up vote
    1
    down vote













    What I suggest might sound harsh, but it has worked for me.



    I was in a similar situation with some slight differences. And what I did was not to offer any advice or help or instructions unless my colleague asked himself. I started to do so because a few times when I offered my help my colleague seemed upset about the fact that someone with less experience and knowledge might actually know better, and sometimes he even said thing like "it can't be so" or "are you sure?".



    Nevertheless, I was always willing to help whenever he approached me first or our manager asked to help him. And in a while his attitude began to change.



    My advice is not to try convince him anything unless it directly affects you or the project. If he wants to upgrade his IDE and break his environment, let him do it. You said that he ignored your opinion anyway. Don't spend your time _ it's valuable both for you and your company. When your colleague needs your advice and is hopefully ready to accept/consider it, he'll approach you himself.






    share|improve this answer



























      up vote
      0
      down vote













      Some people listen to other people, other people plow into something and learn it from the details of code. It sounds like there's a natural division here, you do client relations and he does the coding. However, that's probably silly.



      I'm surrounded by all kinds of people that know how to play with the latest development tools, robots, 3D printers, laser cutters, etc. but act kind of bewildered when they get jerked around by their car mechanic. In short, this person lives in a separate reality, and the things you're talking about 'don't exist' in his world. You might find that if the two of you were in a conference with your client, and your client was explaining the purpose of some mods, your co-worker would zone out. Is he ignoring you, or everyone else too?



      'Upgrading an IDE' sounds like something he could do on a separate machine or boot partition, therefore it might be helpful to have him set up the new one before taking down the old one. Once he has the new one set up, have him import the projects, compile them, and see what kind of error codes pop up. My personal experience with this kind of stuff came about with old versions of Entity Framework, if that suggests anything. In short, does he have to do this to realize there will be material consequences, and that it isn't in the schedule or the budget to do that refactoring?






      share|improve this answer




















      • In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
        – Pureferret
        Jan 17 '14 at 0:40










      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%2f18177%2fconflict-of-knowledge-with-a-colleague%23new-answer', 'question_page');

      );

      Post as a guest

























      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









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      9
      down vote



      accepted










      You can stop creating problems (this IDE upgrade isn't going to work!) and start fixing problems (that new IDE won't support my stuff, and swapping IDEs is a pain. How about X?).



      Because at the face of it, it sounds as your colleague doesn't respect you. Especially among developers, respect comes with your ability to solve problems. As soon as you start creating impediments or not offering solutions you get lumped in with management, marketing, and customers; not a peer to work with.



      I might be wrong, and this is a guess. In the end, to share knowledge more effectively you'll need to get your colleague to value your knowledge. Sometimes that means having better knowledge, sometimes it's showing how that knowledge is valuable, sometimes it means making the nuance of the knowledge more understandable... But if they don't value what you're selling, they'll tune you out.






      share|improve this answer




















      • Absolutely agree. I hope that's what happened in my case.
        – superM
        Jan 17 '14 at 14:53






      • 5




        Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
        – SpYk3HH
        Jan 17 '14 at 15:26














      up vote
      9
      down vote



      accepted










      You can stop creating problems (this IDE upgrade isn't going to work!) and start fixing problems (that new IDE won't support my stuff, and swapping IDEs is a pain. How about X?).



      Because at the face of it, it sounds as your colleague doesn't respect you. Especially among developers, respect comes with your ability to solve problems. As soon as you start creating impediments or not offering solutions you get lumped in with management, marketing, and customers; not a peer to work with.



      I might be wrong, and this is a guess. In the end, to share knowledge more effectively you'll need to get your colleague to value your knowledge. Sometimes that means having better knowledge, sometimes it's showing how that knowledge is valuable, sometimes it means making the nuance of the knowledge more understandable... But if they don't value what you're selling, they'll tune you out.






      share|improve this answer




















      • Absolutely agree. I hope that's what happened in my case.
        – superM
        Jan 17 '14 at 14:53






      • 5




        Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
        – SpYk3HH
        Jan 17 '14 at 15:26












      up vote
      9
      down vote



      accepted







      up vote
      9
      down vote



      accepted






      You can stop creating problems (this IDE upgrade isn't going to work!) and start fixing problems (that new IDE won't support my stuff, and swapping IDEs is a pain. How about X?).



      Because at the face of it, it sounds as your colleague doesn't respect you. Especially among developers, respect comes with your ability to solve problems. As soon as you start creating impediments or not offering solutions you get lumped in with management, marketing, and customers; not a peer to work with.



      I might be wrong, and this is a guess. In the end, to share knowledge more effectively you'll need to get your colleague to value your knowledge. Sometimes that means having better knowledge, sometimes it's showing how that knowledge is valuable, sometimes it means making the nuance of the knowledge more understandable... But if they don't value what you're selling, they'll tune you out.






      share|improve this answer












      You can stop creating problems (this IDE upgrade isn't going to work!) and start fixing problems (that new IDE won't support my stuff, and swapping IDEs is a pain. How about X?).



      Because at the face of it, it sounds as your colleague doesn't respect you. Especially among developers, respect comes with your ability to solve problems. As soon as you start creating impediments or not offering solutions you get lumped in with management, marketing, and customers; not a peer to work with.



      I might be wrong, and this is a guess. In the end, to share knowledge more effectively you'll need to get your colleague to value your knowledge. Sometimes that means having better knowledge, sometimes it's showing how that knowledge is valuable, sometimes it means making the nuance of the knowledge more understandable... But if they don't value what you're selling, they'll tune you out.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jan 17 '14 at 14:16









      Telastyn

      33.9k977120




      33.9k977120











      • Absolutely agree. I hope that's what happened in my case.
        – superM
        Jan 17 '14 at 14:53






      • 5




        Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
        – SpYk3HH
        Jan 17 '14 at 15:26
















      • Absolutely agree. I hope that's what happened in my case.
        – superM
        Jan 17 '14 at 14:53






      • 5




        Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
        – SpYk3HH
        Jan 17 '14 at 15:26















      Absolutely agree. I hope that's what happened in my case.
      – superM
      Jan 17 '14 at 14:53




      Absolutely agree. I hope that's what happened in my case.
      – superM
      Jan 17 '14 at 14:53




      5




      5




      Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
      – SpYk3HH
      Jan 17 '14 at 15:26




      Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
      – SpYk3HH
      Jan 17 '14 at 15:26












      up vote
      1
      down vote













      when i see this happening instead of proxying for the client (pointing out potential issues on the clients behalf) i say to the person involved "oh, you might want to check in with X before you do that" where X is someone with more authority and will likely block the move. That way you don't waste time talking to a brick wall, also over time your colleague might develop a mental checklist of potential client impacts from any desired changes (sounds like this checklist is simply not present at the moment).



      if they don't listen to you and don't "check in with X" (X being senior) then likely a spot of bother will ensue and you can watch them as they work to mop up the spill. Enough spills and eventually they might just start to listen to you.






      share|improve this answer
























        up vote
        1
        down vote













        when i see this happening instead of proxying for the client (pointing out potential issues on the clients behalf) i say to the person involved "oh, you might want to check in with X before you do that" where X is someone with more authority and will likely block the move. That way you don't waste time talking to a brick wall, also over time your colleague might develop a mental checklist of potential client impacts from any desired changes (sounds like this checklist is simply not present at the moment).



        if they don't listen to you and don't "check in with X" (X being senior) then likely a spot of bother will ensue and you can watch them as they work to mop up the spill. Enough spills and eventually they might just start to listen to you.






        share|improve this answer






















          up vote
          1
          down vote










          up vote
          1
          down vote









          when i see this happening instead of proxying for the client (pointing out potential issues on the clients behalf) i say to the person involved "oh, you might want to check in with X before you do that" where X is someone with more authority and will likely block the move. That way you don't waste time talking to a brick wall, also over time your colleague might develop a mental checklist of potential client impacts from any desired changes (sounds like this checklist is simply not present at the moment).



          if they don't listen to you and don't "check in with X" (X being senior) then likely a spot of bother will ensue and you can watch them as they work to mop up the spill. Enough spills and eventually they might just start to listen to you.






          share|improve this answer












          when i see this happening instead of proxying for the client (pointing out potential issues on the clients behalf) i say to the person involved "oh, you might want to check in with X before you do that" where X is someone with more authority and will likely block the move. That way you don't waste time talking to a brick wall, also over time your colleague might develop a mental checklist of potential client impacts from any desired changes (sounds like this checklist is simply not present at the moment).



          if they don't listen to you and don't "check in with X" (X being senior) then likely a spot of bother will ensue and you can watch them as they work to mop up the spill. Enough spills and eventually they might just start to listen to you.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 17 '14 at 13:36









          user3139334

          553




          553




















              up vote
              1
              down vote













              What I suggest might sound harsh, but it has worked for me.



              I was in a similar situation with some slight differences. And what I did was not to offer any advice or help or instructions unless my colleague asked himself. I started to do so because a few times when I offered my help my colleague seemed upset about the fact that someone with less experience and knowledge might actually know better, and sometimes he even said thing like "it can't be so" or "are you sure?".



              Nevertheless, I was always willing to help whenever he approached me first or our manager asked to help him. And in a while his attitude began to change.



              My advice is not to try convince him anything unless it directly affects you or the project. If he wants to upgrade his IDE and break his environment, let him do it. You said that he ignored your opinion anyway. Don't spend your time _ it's valuable both for you and your company. When your colleague needs your advice and is hopefully ready to accept/consider it, he'll approach you himself.






              share|improve this answer
























                up vote
                1
                down vote













                What I suggest might sound harsh, but it has worked for me.



                I was in a similar situation with some slight differences. And what I did was not to offer any advice or help or instructions unless my colleague asked himself. I started to do so because a few times when I offered my help my colleague seemed upset about the fact that someone with less experience and knowledge might actually know better, and sometimes he even said thing like "it can't be so" or "are you sure?".



                Nevertheless, I was always willing to help whenever he approached me first or our manager asked to help him. And in a while his attitude began to change.



                My advice is not to try convince him anything unless it directly affects you or the project. If he wants to upgrade his IDE and break his environment, let him do it. You said that he ignored your opinion anyway. Don't spend your time _ it's valuable both for you and your company. When your colleague needs your advice and is hopefully ready to accept/consider it, he'll approach you himself.






                share|improve this answer






















                  up vote
                  1
                  down vote










                  up vote
                  1
                  down vote









                  What I suggest might sound harsh, but it has worked for me.



                  I was in a similar situation with some slight differences. And what I did was not to offer any advice or help or instructions unless my colleague asked himself. I started to do so because a few times when I offered my help my colleague seemed upset about the fact that someone with less experience and knowledge might actually know better, and sometimes he even said thing like "it can't be so" or "are you sure?".



                  Nevertheless, I was always willing to help whenever he approached me first or our manager asked to help him. And in a while his attitude began to change.



                  My advice is not to try convince him anything unless it directly affects you or the project. If he wants to upgrade his IDE and break his environment, let him do it. You said that he ignored your opinion anyway. Don't spend your time _ it's valuable both for you and your company. When your colleague needs your advice and is hopefully ready to accept/consider it, he'll approach you himself.






                  share|improve this answer












                  What I suggest might sound harsh, but it has worked for me.



                  I was in a similar situation with some slight differences. And what I did was not to offer any advice or help or instructions unless my colleague asked himself. I started to do so because a few times when I offered my help my colleague seemed upset about the fact that someone with less experience and knowledge might actually know better, and sometimes he even said thing like "it can't be so" or "are you sure?".



                  Nevertheless, I was always willing to help whenever he approached me first or our manager asked to help him. And in a while his attitude began to change.



                  My advice is not to try convince him anything unless it directly affects you or the project. If he wants to upgrade his IDE and break his environment, let him do it. You said that he ignored your opinion anyway. Don't spend your time _ it's valuable both for you and your company. When your colleague needs your advice and is hopefully ready to accept/consider it, he'll approach you himself.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 17 '14 at 14:11









                  superM

                  2,34421927




                  2,34421927




















                      up vote
                      0
                      down vote













                      Some people listen to other people, other people plow into something and learn it from the details of code. It sounds like there's a natural division here, you do client relations and he does the coding. However, that's probably silly.



                      I'm surrounded by all kinds of people that know how to play with the latest development tools, robots, 3D printers, laser cutters, etc. but act kind of bewildered when they get jerked around by their car mechanic. In short, this person lives in a separate reality, and the things you're talking about 'don't exist' in his world. You might find that if the two of you were in a conference with your client, and your client was explaining the purpose of some mods, your co-worker would zone out. Is he ignoring you, or everyone else too?



                      'Upgrading an IDE' sounds like something he could do on a separate machine or boot partition, therefore it might be helpful to have him set up the new one before taking down the old one. Once he has the new one set up, have him import the projects, compile them, and see what kind of error codes pop up. My personal experience with this kind of stuff came about with old versions of Entity Framework, if that suggests anything. In short, does he have to do this to realize there will be material consequences, and that it isn't in the schedule or the budget to do that refactoring?






                      share|improve this answer




















                      • In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                        – Pureferret
                        Jan 17 '14 at 0:40














                      up vote
                      0
                      down vote













                      Some people listen to other people, other people plow into something and learn it from the details of code. It sounds like there's a natural division here, you do client relations and he does the coding. However, that's probably silly.



                      I'm surrounded by all kinds of people that know how to play with the latest development tools, robots, 3D printers, laser cutters, etc. but act kind of bewildered when they get jerked around by their car mechanic. In short, this person lives in a separate reality, and the things you're talking about 'don't exist' in his world. You might find that if the two of you were in a conference with your client, and your client was explaining the purpose of some mods, your co-worker would zone out. Is he ignoring you, or everyone else too?



                      'Upgrading an IDE' sounds like something he could do on a separate machine or boot partition, therefore it might be helpful to have him set up the new one before taking down the old one. Once he has the new one set up, have him import the projects, compile them, and see what kind of error codes pop up. My personal experience with this kind of stuff came about with old versions of Entity Framework, if that suggests anything. In short, does he have to do this to realize there will be material consequences, and that it isn't in the schedule or the budget to do that refactoring?






                      share|improve this answer




















                      • In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                        – Pureferret
                        Jan 17 '14 at 0:40












                      up vote
                      0
                      down vote










                      up vote
                      0
                      down vote









                      Some people listen to other people, other people plow into something and learn it from the details of code. It sounds like there's a natural division here, you do client relations and he does the coding. However, that's probably silly.



                      I'm surrounded by all kinds of people that know how to play with the latest development tools, robots, 3D printers, laser cutters, etc. but act kind of bewildered when they get jerked around by their car mechanic. In short, this person lives in a separate reality, and the things you're talking about 'don't exist' in his world. You might find that if the two of you were in a conference with your client, and your client was explaining the purpose of some mods, your co-worker would zone out. Is he ignoring you, or everyone else too?



                      'Upgrading an IDE' sounds like something he could do on a separate machine or boot partition, therefore it might be helpful to have him set up the new one before taking down the old one. Once he has the new one set up, have him import the projects, compile them, and see what kind of error codes pop up. My personal experience with this kind of stuff came about with old versions of Entity Framework, if that suggests anything. In short, does he have to do this to realize there will be material consequences, and that it isn't in the schedule or the budget to do that refactoring?






                      share|improve this answer












                      Some people listen to other people, other people plow into something and learn it from the details of code. It sounds like there's a natural division here, you do client relations and he does the coding. However, that's probably silly.



                      I'm surrounded by all kinds of people that know how to play with the latest development tools, robots, 3D printers, laser cutters, etc. but act kind of bewildered when they get jerked around by their car mechanic. In short, this person lives in a separate reality, and the things you're talking about 'don't exist' in his world. You might find that if the two of you were in a conference with your client, and your client was explaining the purpose of some mods, your co-worker would zone out. Is he ignoring you, or everyone else too?



                      'Upgrading an IDE' sounds like something he could do on a separate machine or boot partition, therefore it might be helpful to have him set up the new one before taking down the old one. Once he has the new one set up, have him import the projects, compile them, and see what kind of error codes pop up. My personal experience with this kind of stuff came about with old versions of Entity Framework, if that suggests anything. In short, does he have to do this to realize there will be material consequences, and that it isn't in the schedule or the budget to do that refactoring?







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jan 17 '14 at 0:31









                      Meredith Poor

                      8,8661730




                      8,8661730











                      • In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                        – Pureferret
                        Jan 17 '14 at 0:40
















                      • In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                        – Pureferret
                        Jan 17 '14 at 0:40















                      In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                      – Pureferret
                      Jan 17 '14 at 0:40




                      In this specific example we use two languages within eclipse. A concern for me is that by upgrading we'll break the plugin that one language runs on. His solution is to maintain two seperate versions of the IDE. He would get to use his new IDE, and the developers who use the 'old' language use the old IDE. I however do about 50:50 in both languages on code where they inter act, so I would need to shut one version down, load the new version, code, rinse and repeat. The issue is, on that he won't ever see the issue firsthand.
                      – Pureferret
                      Jan 17 '14 at 0:40












                       

                      draft saved


                      draft discarded


























                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f18177%2fconflict-of-knowledge-with-a-colleague%23new-answer', 'question_page');

                      );

                      Post as a guest

















































































                      Comments

                      Popular posts from this blog

                      What does second last employer means? [closed]

                      List of Gilmore Girls characters

                      Confectionery