My colleague has a strange way of answering things, When asked about something, he would be "That is my job, or my side of work/coding. Don't need to worry about that."

So it had me asking myself, should I share my knowledge as when my colleague is over, he would not tell me his part of code rather a quick answer like copy paste and would ask me full description of what i do, and what does that.

It is a sign that I shouldn't share my knowledge or contribute to documentation (as my peer wouldn't and me and my PM are the only person who does).

Whereas my peer is very keen to know, what I do, and want to defend his way is better (because he think my job skills rest with him too e.g. he is a dev and a i am designer).

How open should be about my task with him and open to him, as he likes to put it. "Don't worry it is my problem or my portion of code" but would ask me, why and how for my code even he doesn't know basis.

  • 2
    Daily stand-ups are not intended to discuss how you implemented a solution. – Steve Feb 1 '17 at 12:42
  • @DarrenYoung I have edited the question. – user15704 Feb 1 '17 at 12:50
  • Are you both supposed to be doing the same thing, or do you have clearly different responsibilities? (ie one of you is a coder and the other a designer?) – Erik Feb 1 '17 at 13:29
  • @Erik Yes, we both are different people but he like to take a shot, even if it is a bluff. He wanna give illusion of knowing things, whereas he is a learner and 6 years behind me. – user15704 Feb 1 '17 at 13:44

his "attitude" of "If my thing isn't working. Leave it and do your work" raises a alarm for me.

Why? It's your colleague's responsibility, he understands the issue better than you cause he's been working at it, and doesn't wanna spend his time explaining to you why your solution may not apply when there's better things to do. That's one reading of the situation, of course, it's impossible to know your situation from a single post.

The issue here is not your being valued, it's your colleagues perception of you attempting to meddle with things he's responsible for.

It is a sign i shouldn't share my knowledge or contribute to documentation (as my peer wouldn't and me and my PM are the only person who does).

You should share your knowledge when your advice is solicited, and you should update documentation when it's warranted.

In an earlier question of yours the issue of different expectations by you and your manager was raised; maybe your colleague's reluctance to listen to your advice is a manifestation of the same problem.

  • 4
    I agree with this. SCRUM meetings are meant to be short, I myself dislike when our scrum meetings get over 10minutes, it steals time and most of the times I must hear things I really don't care about for my current development. If I have a problem I expect my coworkers to help when needed, not to tell every problem they face in the SCRUM meetings – Mario Garcia Feb 1 '17 at 11:25
  • 2
    The idea that it's "your colleague's responsibility" does not mesh with the rules of scrum, which make all work the entire team's responsibility. – Erik Feb 1 '17 at 11:47
  • @Erik I'm not familiar with scrum. I'm skeptical this would work with a very large codebase but I guess it's manageable for small or greenfield projects, or adopting it very early. Anyhoo, I'm assuming OP's team doesn't follow SCRUM to the letter. – rath Feb 1 '17 at 12:53
  • Guess not, as the OP removed references to scrum from his question. I'll remove my downvote when it stops being locked in :/ – Erik Feb 1 '17 at 13:31
  • 1
    I would add that you are paid to perform tasks - one of which is to share knowledge when asked. It is unprofessional to refuse to share knowledge just because you don't like someone or feel he doesn't value you enough. His possible unprofessional behavior is between him and his manager, it is never an excuse for you to not behave professionally yourself. – HLGEM Feb 1 '17 at 16:01

In withholding information, your colleague is creating a bus factor problem. This is something you should discuss with them and/or your manager. It might not be your responsibility now, but if he's on holiday (or quits) you'll still have to be able to fill in for him and he's making that harder.

This also goes the other way around; you should volunteer information and keep documentation up to date as much as is reasonably possible. Not just so your colleague will have an easier time fixing a bug in your code if you leave. Also because it reduces the odds of being called when you're on vacation. You want to make sure other people can take over your duties when you have other things to do.

However. Staying up to date with what he's doing is very different from criticizing his work. Make sure you approach this purely as a "I'd like to know what you do, in case I need to fall in for you someday" and not as an "My approval of your work is important." Don't raise any issues unless they're potentially ruinous and even then, try to do it respectfully.

  • Are they really creating a bus factor problem? The OP is not a developer after all. – Nathan Cooper Feb 2 '17 at 10:16
  • @NathanCooper from the comments, they seem to be in the same line of business. (Admitted; the OP isn't very clear on what exactly is going on) – Erik Feb 2 '17 at 10:18
  • Sure. I'm just not very clear what's going on. – Nathan Cooper Feb 2 '17 at 11:05