21

I am a Full Stack developer at a Startup company. There is a guy (with 3 yrs of experience) working on the same project that I am, who forces me to make changes to some codes. Even though I point out, why it won't work, he still does not understand. He keeps pushing me to do it. Sometimes, I like that, because having recently joined, I want to learn and push myself beyond my limit.

But, most often, it's too aggressive and unbearable. Not just that, every time I show him my code, he never likes it (even if there is no mistake in it). He does not like the way it is coded, even though it is in the same format that is followed in the company.

Also very often, he forces me to complete a section of the work even though I have to overtime. He threatens to complain to my boss, if I don't do that.

I assume he is too egoistic and probably haven't fully understand everything in coding as well, because I have never seen him talking about anything (related to code) fundamentally.

How do I handle such a colleague?

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Neo Feb 22 at 12:59
79

Also very often, he forces me to complete a section of the work even though I have to overtime. He threatens to complain to my boss

Pre-empt him and talk to your boss about your issues with him. Don't wait until you're stuck in a meeting with your boss in a defensive position you're not prepared for. You can move forwards from the results of that meeting. Until then you're just a target.

Anything along the lines of.

'Boss I'm sorry, but I'm really having trouble handling all this overtime without warning? Tonight is my chess club etc,.'... 'What overtime?'... 'John keeps telling me I have to finish things before I leave, I assumed on your authority, because he always mentions your name?'...

The best response to a bully is deflect the hit and let him dig himself a hole or even deflect so hard he starts hitting himself while you act mildly surprised that there's even an issue.

13
  • 40
    Telling your boss that your peer is making you finish the peer's ideas with overtime and then threatening to complain to the boss if you don't is a recipie for making sure your boss understands the peer is pulling a major power play against you. If it were me, I'd tell the boss that you'll sometimes help him, as you should; but, with wording like that you feel that you're now working for him due to the explicit threat, and it's making the team dynamic weird. – Edwin Buck Feb 18 at 21:04
  • 20
    Also: Your time is allocated by your boss, not your coworker. – Simon Richter Feb 19 at 12:24
  • 1
    @Kilisi: How do you know that the other person won't deny the whole thing and this will backfire since the OP is the "new guy"? It could work if the other person has a history of doing things like that – Jim Feb 20 at 9:58
  • 1
    @Jim backfire in what way? It's a given that an aggressor will deny and try to gloss over things, and sometimes they're not even aware they're being aggressive. It's all in the delivery, if you deliver facts like a pro (which you should because you have prep time) you have a huge advantage over someone who is responding unprepared. Even innocent people responding unprepared can look like they're dodgy as heck. – Kilisi Feb 20 at 13:29
  • 1
    @Kilisi: No I am not downvoting. Thank you for your time explaining so far – Jim Feb 20 at 21:40
48

Overall, the picture you've painted in your question, and I'll preface my answer with this, is of someone who is a relatively inexperienced developer who is new to a company and learning the ropes but having some trouble. So I'll start there and give you some advice:

Regarding the experienced developer telling you to do things that "don't work": I've been here many times, and I've been on both sides of this situation, both as the inexperienced junior telling the senior that what they want can't be done, except the senior is right and it could actually be done, and also as the experienced senior having a junior tell me that what I want them to do can't be done and having to explain that it can, so I'm intimately familiar with what's going on here. What usually causes this is a lack of experience. The senior developer is usually right when they say something can be done, and the part that's missing is that the junior doesn't know how to do it. To which, if it was me, I would explain to the junior what they need to do and how to do it, but not all senior developers are as generous as I am, and some lash out in frustration.

Here's something to try: Rather than saying "it won't work" or "it can't be done", try asking questions. Instead of "I can't do this, because of XYZ", instead frame it as a question: "If I wanted to do this, I would need to solve problem XYZ, but I can't think of a good solution to that. How would you go about tackling this issue?" A good senior developer would see this as a teaching moment and help you out with that issue to spread their knowledge (note: not all senior developers are good senior developers, so YMMV). A bad senior developer may say something like "that's your problem to figure out", at which point you can ask around to your other coworkers to see if anyone else has an idea, or you can escalate to your boss and say that this senior is not helping you; at most companies it's part of the job description of a senior developer to mentor juniors, and so this is a pretty big issue if he's not doing this.

Another thing to think about is that, if you refuse to do this work (even if it's "impossible"), then someone else has to do it; it has to get done. So when you say "it can't be done", you're not actually saying "it can't be done"; you're actually saying "I won't do it, you have to do it for me", because someone has to do it. Which puts your work on his plate. More on this in a moment.

Regarding code reviews: You used a very poignant word in your question which I think shows the root of the problem. Specifically, you said: "there is no mistake in it". This shows a lack of understanding of the code review process that you need to rectify first. The code review process is not about finding and fixing "mistakes". That's called testing. You test your code to find and fix mistakes, and then once the code has no mistakes, then you send it for code review for other purposes. Specifically, those purposes have to do with things like code style, portability, maintainability, and so on.

Maintainability is the most important and also most often violated part of the code review process so I'll drill a bit more on that one. Basically, the idea is that any code you write should not be understandable only by you. Anyone who reads the code should be able to understand it and, if necessary, fix any bugs in it that might arise, or adjust or augment it in any way. The issue is, if you are the only one who understands the code, and you leave the company, then nobody understands the code, and that's a problem. The code review process is there (in part) to make sure that doesn't happen. Without knowing precisely what comments this other developer is making on your code it's hard to say if the issue is maintainability, but:

Here's something to try: Just do whatever he says. The code review process is intended as a gatekeeping process. Code does not get merged without the approval of at least one other team member. This comes with the responsibility for you that the code is of high quality, and the responsibility for that team member that, if the code is not high quality, then he's on the hook for approving code of low quality. The real truth of code review is that new code is very rarely of high quality; comments on code are normal, and multiple revisions of code are normal. Rather than take these comments and change requests as aggression, take the comments as instruction and teaching: the other developer is taking his time to make comments on your code so that you can learn from them and become a better developer yourself. He's also taking an interest in your code to make sure that it won't break; if the code does break (even if the break is in terms of lack of maintainability and not an actual server crash), then it's your head on the line and you'll be the one who gets punished for it, and this other developer is helping you to make sure that doesn't happen. Treat the code review process with respect; it's not a rubber-stamp process and it's not intended to be.

Working overtime: Normally, I hate working overtime; you can crawl through my SE answer history to see all the times I've written about how bad overtime is. However, this is an exception. In this case, it seems that this other developer (and perhaps your team at large, and this one developer is simply the messenger) sees that you are underperforming: you are saying things "don't work" which this other developer has to then build for you because you can't solve the problem presented to you. You are trying to shirk and complain about the code review process and expecting your subpar code to get rubber-stamped. Don't expect that your boss is not aware of this situation; your boss most certainly is aware.

Here's what's very likely going on behind the scenes: Someone, somewhere, wants you fired, and it's probably not this other developer (it might be your boss). They see that you are underperforming and they see that you are not a good fit for this company, and they want you gone. Someone else has decided that they want to give you a second chance. The idea being that, in the current state of affairs, you are not performing well: you are not completing the tasks assigned to you and you are not presenting work that is up to company standard. However, they see potential in you and they think that eventually this will be fixed. In the meantime, however, the work needs to get done and you are expected to contribute your part. The issue is that you are not able to contribute as much as is required during work hours, so you have to work overtime to complete your expectations.

In essence, someone has put a bet on you and someone has put a bet against you, and right now the person who is putting the bet on you is winning: You can keep your job, and that person will protect you, as long as you get your work done and deadlines met, even if that means working overtime. If you choose not to work overtime, and you fail to meet your deadlines, then the person who is against you will win and you will lose your job.

If you want to keep your job, here's something to try: Take my advice above. Don't say you can't do something, or that something is impossible. Instead, say things like "I don't know how to do XYZ", or "how would you do XYZ", or "I see a problem XYZ, what do you think". And then when that problem gets solved, then you do the work yourself and you deliver results. Then, when you've delivered your code, you accept that your code won't be perfect, you don't take code review comments as an attack, and instead use it as a learning experience to become better, and you do what you're asked to do and you merge your clean code smoothly. In the meantime, you work overtime as necessary to meet your deadlines. Eventually, as you become a better developer, these procedures will go more and more smoothly and you'll find it easier to continue in this situation.

20
  • 9
    I partially agree with this answer, and I'd 100% agree if the guy OP was referencing is indeed a halfway decent senior developer, but I don't really think that's the case from OP's post and comments. The guy has 3 years of experience, which is not generally considered senior at anywhere I've worked. I think it's more likely they're also a junior developer who has merely been at the company longer than OP. – Nate S. Feb 18 at 20:35
  • 14
    @NateS. From my reading of OP's question and comments, it seems like OP is heavily biased against this person, and hence I don't trust OP's characterization of their qualifications (having been in a similar situation to OP in my own past, I understand where he's coming from and know not to trust people in that situation to tell me the honest objective truth). It's probably a lot more grey-area than it appears. – Ertai87 Feb 18 at 20:39
  • 4
    @NateS. I don't trust a junior developer who is new to the company to accurately know what "adhering to the company coding standards" means enough to claim such with certainty (and I certainly know even less as some rando on the internet). This is why my answer does not mention anything about "company coding standards", and that's an intentional omission; if you write clean, maintainable code, then you'll be all good in 99% of cases, so focusing on that should be top priority. – Ertai87 Feb 18 at 20:45
  • 8
    I take it you haven't had the pleasure of working alongside a "senior" developer with many years of experience who still writes unmaintainable spaghetti code. And there are multiple ways to write maintainable code, and some places have a strong preference for one particular way. All I'm saying is that you're making a lot of assumptions that I'll agree are probably true, but aren't definitely true. – Nate S. Feb 18 at 20:57
  • 16
    The whole "somebody probably wants you fired" is I think speculation. Sure there's always things ongoing behind the scenes, but it could be so many things I see no reason to choose this scenario over another. – Laurent S. Feb 18 at 23:32
15

You need to get some one else in to mediate - the project lead, the boss (if that's not the same person), or another senior person.

There are many reasons for rejecting working code in a code review, varying between

  • The code is horrid and unreadable by anyone but its writer, and
  • I wouldn't have coded it like that, so you should change your code to match the way I do things

Without an independent person in to offer a judgement, it's impossible to tell what the real problem is.

2
  • I use company standards, and the Project Leader approves and understands the code, as he is one of the key personnel to develop the coding standards of the company and I follow that strictly.. I fail to understand what's wrong with my co-worker – Asish Feb 19 at 5:10
  • 4
    @Asish consider depersonalising the code review portion, grab a few examples from different people's pull requests and convert it into a presentation style and ask your Project leader if you can bring it up at your next Retrospective or similar review session. See if you can get the team to discuss some of the issues as a group without pointing fingers at who is responsible for which comments. – Jontia Feb 19 at 11:21
5

You have 8 (or whatever it is in your company) hours a day to get work done. If he comes up with changes that you need to do, this uses up some of these hours and therefore uses up the company's time. This is the mentality you need to carry with you: The company is paying you for your time and therefore a waste of your time is a waste of their time.

So you need to find out from your project lead if the changes he's suggesting are really worth the time it will take.

You said in a comment:

I use company standards, and the Project Leader approves and understands the code

So the Project leader will likely side with you. If not and you really have to make the changes, then you'll have to do it, but make sure you understand why so as to avoid making the same "mistake" in future. But at least now they'll understand what is using your time. If it won't be finished today, then do it tomorrow.

Also very often, he forces me to complete a section of the work even though I have to overtime. He threatens to complain to my boss, if I don't do that.

I am having trouble understanding how a colleague who is not your boss can force you to do overtime.

If this is work that is already assigned to you, just tell him you'll get to it tomorrow because you have to leave at [whatever finishing time is]. If he's assigning you this work, - considering he's not your boss / project lead - tell him you have to concentrate on the work that is assigned to you have to do and you don't have time to do his work. If for some reason (you said he was "helping" the Project Leader) he has the authority to assign work to you, then bring up with the Project Leader that the colleague is giving you different work to what the leader has and ask which is the higher priority.

5
  • From what I have understood (about myself) so far, I am way too to insecure talk about my problems to my superior (project lead,etc.) – Asish Feb 19 at 13:21
  • 3
    @Asish - but don't see it as talking about your problems. Think of it more just asking questions about or clarifying how to proceed with your work, the same as you would any other question. e.g. Which bit of work is your priority [the one the project lead gave you or the one the colleague gave you]? Should you spend X hours making these changes to the code even though they already conform to the standard? Remember the colleague doesn't even seem to be giving you a reason for making the change. – colmde Feb 19 at 13:36
  • Okay. I will try, I guess – Asish Feb 19 at 13:39
  • You can easily push back on this individual "requiring" you to do OT. OT is not free work. If you have a project that is expected to take 80 man hours, and you charge those 80 man hours in 8 days instead of 10, you still more then likely have 20 additional man hours (at least) in order to finish that original workload. – Donald Feb 19 at 20:49
  • However, the company still has to pay you for those 80 hours, and the 20 hours, and that all goes on the books as cost towards the project. Additionally, not only do you break the cost associated with the project, you likely are delayed in finishing the work itself. So you are better off allowing the manager to decide what to do about the additional rework. 80 hours = 10 days = 8 hours each day. The only way the project is finished ahead of schedule or under budge is if you are ahead of schedule working 8 hours a day or more than 8 hours a day within the 80 hour budget. – Donald Feb 19 at 20:50
1

He only does not like it, for reasons only known to him.

The next time this happens, follow up your conversation with an instant message or an email that says:

"I know you want me to change the code in my latest commit and I'm willing to make any change you want, but before I can change anything, I need to know the reasons why. If I don't understand what your coding standards are, then there is actually little chance for me to meet those standards."

Or if the person already bullied you in accepting to make a change. This is what you write at the beginning:

"I'm sorry, but I changed my mind. I know you..."

And if he comes over and tries to explain what he wants.

Tell him: "No man, if you want me to make those changes (that the tech lead already reviewed and approved), tell me in writing. I understand your ideas much better when they're written down."

Just be careful when you say this, you do not want every interaction to be written down, that would be folly. Nor do you want to insult him when you say this, or it could come back on you. You just want to say this when you feel his suggestions are counterproductive and when you know the tech lead has already approved your code.

This way, if there is ever a complaint made to management, whether he makes that complaint or you make it, you've got a digital trail to back up your side of the story. So for that reason, be very careful when you craft those emails/chat messages, if they're written well, they will make you look good, if they're written badly, or written when you're angry, they may make you look bad.

even though it is in the same format that is followed in the company.

It could be that your company standards are too broad or not very good.

In which case, if one day he suggests a standard that you agree with, lobby to change those company standards (properly giving him the credit).

And please, don't tell us that he's never helpful. He's got to be helpful and he's got to have good ideas sometimes, as rare as those times may be, otherwise, you wouldn't be going to him for feedback in the first place. Try to find the good in people, even if it's hard to find.

7
  • Thanks for pointing out about 'never'. English is not my first language, so you may see a lot of mistakes there. Secondly, I have worked with him for like 2 weeks, and never he has helped me which actually helped me complete my task. He would have made my life a lot miserable, had the manager (of the company) not intervened. I go to him for feedback, because he (along with a few other senior devs) went on to discuss the requirements of the client, and I was on leave. Since our company is a startup based, other senior devs are focussed on other projects and I an struck with it. – Asish Feb 21 at 5:17
  • @Asish, Actually, I wasn't talking about an English mistake. Your English is perfect. I was talking about something else. I'll remove that part because it detracts from my answer. What is the reputation of that developer among the other developers? Is he a difficult person to be around? If that's the case, his complaints may not be taken seriously by management. – Stephan Branczyk Feb 21 at 5:23
  • I am not sure about the reputation of that developer, because I am a newbie, and kind of an introvert. But, our project leader disagrees with him very often. – Asish Feb 21 at 6:56
  • @Asish, Well, try to get out of your shell if you can. The more extroverted you are, the better you'll be at defending your work. And do ask people around. If people don't like him, you should be able to find out. No one will say anything overtly bad, but you can usually tell from the tone of their voice, or from the way they try to answer your question diplomatically. If he has been a problem for you, he has been a problem for others most likely. – Stephan Branczyk Feb 21 at 7:05
  • Yeah! I will ask around, as to how he is with other co-workers. – Asish Feb 21 at 7:19

You must log in to answer this question.

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