2

I'm a junior developer working in a small team of about 10-12 core developer and some technical people. I've been working with this team for about three years. We're all pretty close and spend a lot of time together outside of work as well. However, one of the senior developers (whom I'll call "X") doesn't seem to trust my work. I find this rather odd because I think I produce decent work and we also have a very robust version control and review process.

  • "X" is often really confrontational when reviewing my code, and seems to get angry if it's not immediately obvious what the code does. I do my best to write clean code and comments.

  • "X" also avoids using any helper scripts if I've written them, even if they save time (e.g., setup a test environment that's time-consuming and typing-intensive). All the other developers use my scripts and seem to like it.

  • "X" doesn't seem to trust my code, even after it's been tested and released to production. "X" also never believes me (initially) when I find bugs.

Oddly, "X" is actually a really nice person."X" is always the first to offer to help and explain things and is patient. I genuinely like "X" as a person, and we have a good time together, whether at work or after.

I don't think I've ever given "X" a reason to doubt my work. After almost three years, I'm not sure how to gain "X"'s trust. I just want "X" to see me as a contributing member of the team, and also take me seriously when I find/fix bugs.

How can I discuss this with X? Should I?


Some potentially important factors:

  • I'm the youngest developer in the team. I joined the company straight out of university. The next youngest person on the team is two years older than me. "X" is about 10 years older than me.
  • I didn't have any prior experience with the languages they use (except C/C++). However, after three years I feel very comfortable with them.
1

3 Answers 3

8

Don't take criticism personally or get emotional. Focus on solving the problem instead of confrontation.

"X, I see a code review comment that this code is unclear. Could you suggest how it could be improved?"
"X, was there a reason why helper script couldn't be used here?" (and/or) "X, how can we enhance helper script so that it can be used in this scenario?"

Don't make it an issue of "your" criticism of "my" code, or "your" non-use of "my" script. Don't bring up how "others" don't have a problem with "my" code or "my" script. That only creates problems and doesn't help improve anything.

Your goal should be to understand and address his concerns. This would lead to one of the following scenarios:

  • You learn something from him in the process, and get to improve your coding/scripting skills and/or understanding of software design/business.
  • You politely and respectfully convince him how the existing code/script already addresses his issue.
  • You both have strong and conflicting opinions about the topic, and you agree to disagree and move on. Given that he is the senior developer, you would most likely have to do things as he says even if you respectfully (and perhaps, rightly!) disagree with him.
3
  • I'm having a hard time understanding how "X, was there a reason why helper script couldn't be used here?" is not "your" non-use of "my" script.
    – BlindSp0t
    Nov 14, 2017 at 15:04
  • @Blind Technically, it is not, the trick is to spin your words carefully. Rather than saying, "why havent you used my script?", you say the above. That shifts the focus from "you" and "me" to "what did we miss in making the script usable". However, if someone tries to pull that trick on me, for example, I can easily see through that bullshit.
    – Masked Man
    Nov 14, 2017 at 18:10
  • Ah gotcha. Great answer too.
    – BlindSp0t
    Nov 15, 2017 at 15:00
5

It's called 'Playing the devils advocate' and is a legitimate strategy to help in troubleshooting and resolution. It's not a matter of trust, they're not getting paid to trust anyone, they believe quite the opposite.

In probability the chap does not have any personal issue with your work at all. I use this strategy quite a bit because it keeps people on their toes producing good quality work. In the same manner that I will doublecheck a senior engineers work 'just to make sure' even though I know they're competent.

2
  • I don't know. This: ""X" is often really confrontational when reviewing my code, and seems to get angry" doesn't sound like "playing devil's advocate" to me. I work with people who are able to do that, and it's not confrontational, nor do they get angry. Nov 13, 2017 at 4:42
  • I think this goes beyond "playing devil's advocate". We're persons, and we can't detach emotion from constant criticism. Is my boss is constantly telling me my work is sh*t I'm not going to write "better code" to please him: after some time it will be obvious I can't please him, so I'll just become jaded and write sh*t code, or quit the company.
    – hjf
    Feb 13, 2019 at 15:40
1

Consider these options:

  • On what people say above: ask if your colleagues feel the same.
    • Maybe it's a defense or opposite a way of him to teaching you or both. What if you are the smartest and mo promising developer on the team? He might feel both threatened and (proud/wanting to train you) at the same time. the way how he subconsciously responds to you is totally logical.

Anyway best advice is to talk about it openly. Ask for a performance meeting (about you) and drop these questions you have.

You must log in to answer this question.

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