Conflict of knowledge with a colleague

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?