How to deal with a senior dev that does not trust your skill

Question

It has been four months when I last ask a question about advice. Here I am again. I've been working on my first ever programming job coming from a non-IT background for four months now. Recently, I felt like a senior dev does not trust my skill. I am not sure though if every senior is or should be like that. After all, they know better than anyone else. Thing is, I happen to notice that on all of the members on our team I am the one he/she is the strictest. For example, on code review we had a new guy as well whom he/she just pass the code review, then when I check the code I was very disappointed with how it passed. The code was full of redundancy code I don't know how it passed. While I, on the other hand, will get rejected on the wrong indention or wrong spelling of a function or a variable even if it's only one. He/She most of the time reject the solution I had in mind and would push his/her solution. Thing is if I asked why he/she would give me an unsatisfactory answer. I always asked the reason behind a solution to understand it better cause I think learning something without why is really pointless. I am glad that I am learning a lot but I don't know.

Answer 1

On code review we had a new guy as well whom he/she just pass the code review, then when I check the code I was very disappointed on how it passed. The code was full of redundancy code

The purpose of code review is to solicit feedback from peers to improve code quality and avoid code smells. If you have ideas around those, you should contribute them to the pull requests reviews. If suitably provided, these will help you build credence with others, including the senior dev.

While I on the other hand will get rejected on wrong indention or wrong spelling of a function or a variable

The mistakes above are actual code checks that matter at most companies, code readability is a must for future debugging. Just because a code review identified problems of one type, doesn’t mean the code is free of all other types of possible problems. I would suggest to take these code reviews as an opportunity to learn and not make those mistakes next time onwards.

He/She most of the time reject the solution I had in mind and would push his/her solution. Thing is if I asked why he/she would give me an unsatisfactory answer.

As a senior dev, one’s time may be constrained with how much of explanation he/she can do. They may also have a better understanding of future requirements, and past decisions, which may lead them to bias their solutions. If you feel unsatisfied with the answers, talk to your other team mates informally on what are the possible benefits of the solutions that are adopted. Organisations are not ideal entities where the best solutions always win, it is usually a compromise around something that gets done in time and satisfies the majority of objectives at hand.

Recently, I felt like senior dev does not trust my skill

Since you’ve been there for just 4 months, and come from a different background previously, I would suggest to focus on real learning that helps you grow as an individual contributor rather than on the personal attention a senior dev does or doesn’t give to you. Learning different paradigms can take time for you, and it is quite possible that your beginner level questions may not be appreciated by the senior dev. This should hopefully go down over a period of time once you get a better hang of the various pieces involved.

Answer 2

I am a senior developer in a situation similar to this.

In my case, the junior programmer also complains that I will let redundant code through for others, while complaining about stylistic things in their PRs. That doesn't make sense, at first - we're told to avoid redundant code!

The junior I'm dealing with, however, applies that principle too much. I've often found that their solutions are over-abstracted, to the point where it's both harder to read the code and harder to extend it.

For example, just recently they noticed that two methods for updating a piece of state were similar, so instead of having

class Security:
  def add_lock(self, end_time):
    ...


  def add_price(self, price):
    ...

They did something like

class Security:
  def add_thing(self, thing, datatype):
      ...

In the interest of removing the redundancy around adding a lock and adding a price (the body happened to be the same in both functions).

However - adding a lock was very different from adding a price! It turned out my junior missed some functionality that was required in the case of adding a lock, some ~100 lines or so. To extend their new function, we would have to add in a bunch of code unrelated to just any type of thing.

I flagged their code on a couple of levels. For one, removing the redundancy was nowhere near as beneficial as having the readability of clearly defined functions for adding locks and prices. Another point in favor of the redundant code is that it is easy to extend if it turns out locks and prices don't have much in common (they didn't).

Don't Repeat Yourself (DRY) is an important principle, but it's not the only important principle in programming. You're bound to learn more as you grow. One that I always find useful comes from Rob Pike at Google (creator of the Go programming language). He says, "A little copying is better than a little dependency". And while that's not always true, it is something you'll develop a feeling for as you do more programming.

You're still learning! There are probably things you're just not getting at the moment. That is totally OK, by the way. I would push hard to find out why the senior keeps giving unsatisfactory explanations. It could be that your senior is wrong. But it could also be that you should be finding the explanations satisfactory, and aren't because you don't have the experience yet.

Answer 3

A possibility that you should consider is that your code reviews are strict because someone genuinely wants you to improve (and apparently doesn't care about the other new team member). That's the good one. A bad possibility is that someone dislikes you and intentionally gives you a hard time. You'll have to figure out which one it is.

As long as you think you are improving because of harsh criticism, then don't focus on the criticism but on the improvement. Look at any unfair criticism not as your problem, but as the problem of the critic.

About rejecting one solution and replacing it with his own: Every single problem has several solutions. Some better, some less good. Some that look good, but with lots of experience you just know that it will eventually get you into trouble. The reason for that is sometimes hard to explain. Sometimes you don't even know the reason, you just know this solution will not work long term. It may be that your solution was that kind of solution. It may be that he was just full of it. Hard to say which one.

I'd say as long as you feel you are genuinely improving you are Ok. Remember to be nicer to the next junior when you are the senior developer.