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?

  • 3
    You might find reading a book about interpersonal communication useful. Something like How to win friends and influence people.
    – user10911
    Commented Jan 17, 2014 at 0:28
  • @geekrunnings I've seen the name of that book batted about, I might look into it. Commented Jan 17, 2014 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
    Commented Jan 17, 2014 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...'. Commented Jan 17, 2014 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
    Commented Jan 17, 2014 at 17:25

4 Answers 4


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.

  • Absolutely agree. I hope that's what happened in my case.
    – superM
    Commented Jan 17, 2014 at 14:53
  • 6
    Especially among developers, respect comes with your ability to solve problems WOW! Could not have put that better myself. So friggin' true!
    – SpYk3HH
    Commented Jan 17, 2014 at 15:26

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.


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.


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?

  • 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. Commented Jan 17, 2014 at 0:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .