I work in a team where I am more experienced and have a better understanding of the work than my colleagues, and was hired for this reason.

Unfortunately a colleague of mine, who has been here for a long time, is taking an uncomfortable level of interest in the work that I am doing, and want's to take the lead.

The problem is that he does not know the basics of what I do, and is trying to take over the work that is already high level. He want's me to teach him everything as we go along, but also will not tell me about the code that he is working on. If his code won't validate, or something looks strange and won't work as expected, and I bring this up, then he has a strong (negative) reaction.

His point of view is;

"It doesn't matter if the code is spaghetti, or tags are not closed correctly if it works."

This is making my job harder, sure I understand that the end result is what is needed but when I start doing my work as a front end guy, I am shocked by the quality of the code and I spend x3 more time doing something than it normally needs.

It seems like he wants to show the manager that he is better at everything. But in the end, I am given code to (working from the back end perspective and have me done front end correct as well while bootstrapped logic missing hence making my job difficult) do my part of job.

The manager doesn't seem to be a person who would want to understand my work as he is a PM and wants to get the job get done right and quickly (even he does try to copy and paste my work and when he is not able to make it work, asks me) and trust my colleague more than me, as I have been on my job for 2 months and my colleague and the PM have done 5 yrs.

How can I make the point that everyone needs to work together to make the job easier/better, so in the future the product is stable and easy to use?

  • 3
    2 words: code review. You review his code, he reviews yours. You both set some minimum guidelines (you won't like how they start) but then the process of knowledge sharing starts.
    – adeady
    Commented Dec 21, 2016 at 13:36
  • I agree with @adeady Code Review will really help here. You're co-worker may not be willing to do this though, or may not appreciate it very much (I don't like it myself, even though I know it's good for me) So make sure to approach this with caution. One funny way is to ask for a code review of your code, where you have encapsulated their work as well, ("code review this whole file please, I made some changes")
    – TolMera
    Commented Dec 21, 2016 at 13:57
  • 3
    "It doesn't matter if the code is spaghetti, or if tags are not closed right as long as it doesn't have any issues." LOL - who said that, you or him? :) Because whoever pontificated this piece of hilarity needs to lose his job. Commented Dec 21, 2016 at 14:24
  • 1
    @TolMera I totally agree that you start by asking other people to review YOUR code. It helps make it seem less "I think your code sucks" and more "We should do this, I'm making myself vulnerable first."
    – adeady
    Commented Dec 21, 2016 at 14:47

2 Answers 2


This problem shows up in a lot of small businesses. So I'm going to assume that the business you're working for has less than 5 developers. And answer your question from that points of view.

Problem: 1. Someone elses work is of such a bad quality, that it makes simple things complicated. 2. Someone else want's to know all about what you do, even though they do not have the skill to actually understand what it is that you do 3. You're new to the business, and have not built up that trust with your manager yet.

I'm also going to make one other assumption: The business you're working for does not have a nice HR department who has documented how to do your job, such as how to manage SVN, Coding standards, etc etc etc.

First thing to do: Take a long hard think about if you want to spend the next two years trying to improve the development environment at this job. If the answer is "no" start looking for something better. It will have 3 or 4 months for you to get totally sick of this job and it's issues, so that's plenty of time to do job hunting.

If the answer is "yes I'm willing to work really really hard, and never be thanked for working really really hard, but I'm willing to do this anyway because I really think this company is worth two years of annoyance and trouble" Then congratulations, you're a trooper! Move on to step 2:

Step 2: Tell the person who's looking over your shoulder everything that they ask. When they don't understand something, ask if they would like you to explain it to them. If they say yes, explain the topic as quickly and simply as possible.

WHY? Because the person causing you all the trouble is causing all the trouble because they do not know they are causing trouble! In other (simpler) words, they don't know that they are doing things wrong. Educating them is your first big hurdle.

Step 3: Do all the work that you get given to do, even if it takes you *3 longer than it should! And do a really good job if you can. important: 1) Don't over simplify your code 2) Make sure that your work is really good 3) Write code that can deal with inconsistency. (The best programmers write loose code)

WHY? Because as you write the code, you're making it better! Someones going to have to do this one day, it might as well be you and it might as well be today! As you write better and better code, and slowly bring the system into a consistent formatting standard, use more complex but better structures, you're forcing your colleague to learn how to code better code, because what he does, is going to interact with what you do.

Side benefit: Your code will stand out from your colleagues work, because your code will be consistent, readable and manageable. As you write more and more code, this will make your code look good, and your colleagues code look as hap-hazzard as it truly is.

Step 4: IMPLEMENT AUTOMATED TESTING! The Best of the Best write automated testing!

If only someone had explained this to me five years ago. Automated testing is the "Holy Grail" Testing code makes sure that you don't break core code features, And when you do, you know before anyone else, so you can fix it.

Look for Jenkins it's pretty good. And has basic (or complex) automated testing.

WHY? Because when you run your code through automated testing, even if you can only run this locally, it's the only proof that you have that the code you're writing works like it's meant to! And if you pass all of the code that you write, and all the code that your colleagues write through the automated testing, then when they write something that breaks your work, you know about it straight away, and you can fix it.

Or you can tell them about it so they can fix it.

And when you manager comes to you can tells you that your codes not working, you can tell him/her exactly why it's not working, and exactly what you're going to do to fix this.

Over all it's going to be a really hard couple of years! But at the end of it, things will be better, even though you're the one that has had to to ALL of the hard work. And this is an opportunity for you to learn and grow a HUGE amount over the next couple of years as you improve every aspect of what you do. Even if you leave this business in a couple of years, the skills you will learn doing this will translate to a professional work-space very very well, where you will be doing all of these things I've listed on a daily basis, and you will understand WHY :)

Good Luck!

  • 1
    sure i can explain but it seems like they want to take over, i know i lost a job like that when a colleague wanted to tell him, how do i do what, and what does what, even if i tell him i might become passive and like the nature he has, he might think he i superior e.g he wants to say "Morning" to manager and not me, whereas i sit opposite and PM sits besides him, he is kind of person who want to be in spotlight or say "it doesn't matter" and PM seems to take his route as i was asking my PM something to clarify, PM replied, "i don't care about that, i want this to be look like i want"
    – user15704
    Commented Dec 21, 2016 at 14:00
  • 2
    Hey @Nofel . Yea that's why I started my answer with "Think long & hard if you want to stay there". Problem is there is NOTHING you can do that is going to make him a better person to work with, or fix his attitude problems. The ONLY thing you can do, is be amazing at the job, outshine the guy by being amazing at your job, and use the whole thing as a learning and training opportunity. you have about a 10% chance of this eventually being a good job, and a 90% chance of this being a terrible job. Play the odds and find another employer, or knuckle down and turn it into a good job.
    – TolMera
    Commented Dec 21, 2016 at 14:27
  • 1
    @MisterPositive i am willing to put my effort into it. Nothing is perfect, i admit hard work is the way and i intend to stay like TolMera said and make things right, one page at a time. Just need heavy conviction.
    – user15704
    Commented Dec 21, 2016 at 16:51
  • 1
    @Nofel Your willingness is not in question. I think the PM and your colleague may be friends and you will be fighting an uphill battle. Ask yourself if the juice is worth the squeeze. I would say no in this case, but the final decision is up to you. Good luck.
    – Neo
    Commented Dec 21, 2016 at 16:53
  • 1
    Hey @Nofel I think this might be a conversation for the Workspaces chat area. as this is now turning into a conversation. but to answer your follow up question. You should share all the knowledge that you have with your peer. Reason being, as an employee you are not entitled to hold back any skills or knowledge. Second, this is part of educating your co-worker, thirdly, you get to show off just how much more experienced you are than they. And lastly, yes, business owner generally don't care how things are done, so long as they get the result they want. It's bad practice but common.
    – TolMera
    Commented Dec 22, 2016 at 11:18

People have mentioned code reviews or automated testing, etc. That's all well and good but beside the point. The person you wanna talk to is the PM who doesn't understand coding practices, but understands money.

You need to make the following argument:

Doing things correctly leads to fewer bugs, and when those bugs occur, they take less time to fix. Investing time up-front to come up with a sound design is the only way to ensure our time is spent putting in features, rather than chasing our tails when angry customers complain. Bad practices cost money. Good practices make money.

Chrome and Firefox can take a guess where that open tag should close, but good luck if you ever run it in IE9 or earlier, as some corporations insist on maintaining.

Unfortunately, you will fail. The PM has had 5 years to decide if the other guy's way of doing things is OK, and it works for them. It's not gonna change because of your "mild inconvenience". That's my take on your PM and colleague; they seem friends.

Good luck

  • I agree with this, if you have a good PM, this conversation can make a big difference, especially if you're able to give solid examples of the last X number of support calls that have been a result of something that would have been avoided if you had a good coding standard, or automated testing, or any of a plethora of other small things that make things better. I also agree that the boss and co-worker seem like friends, so there's not a lot of hope for this situation.
    – TolMera
    Commented Dec 21, 2016 at 14:54

You must log in to answer this question.