I have somewhat recently started as a software development consultant at a new company through a 3rd party staffing company. I am working at a very large company, and work with other offices distributed across the US. It has been stated to me that I will be made an offer from the place where I develop after a 6 month period.

I work with 3 to 5 other developers on the same product, with similar sized teams residing in other states. The "managing developer" for this product sits in one of the other offices. The managing developer alone has final say on what pull requests are merged. I will call him "Ted".

Myself, and a few other newer engineers in this office, have noticed problems with the code coming from the other offices. There are frequently issues with the code - pull requests often contain code that will have no effect, or it is plain to see they will have no effect based on the description of the ticket. To further compound issues, many of these pull requests are made by a veteran dev, with a lot of tenure. I'll call him Dave.

The developers from my office frequently call out issues on Dave's code, and they are almost all ignored. Further, we have weekly calls to discuss these pull requests, and they often become heated, with Dave interrupting anyone he disagrees with, and frequently talking over others in defense of his stance. Sweeping architectural decisions are made by this person, and (I suppose you'll have to take my word for it) they frequently have large issues. A lot of this involves "re-inventing the wheel", diverging from known paradigms/structures/mature 3rd party libraries that solve simple problems more robustly than we could.

Compounding the issue, Ted will not intervene to stop Dave's unprofessional behavior. He is not that strong technically, and I think just defaults to following whatever Dave instructs due to familiarity (the pair are located in the same office across the country). Ted frequently merges pull requests that have a lot of valid, unresolved comments on them. Recently, we had a debate between two approaches, and we didn't end up going with Dave's approach. That night after we'd left the office (different timezones), Dave got Ted to merge his PR instead of the team's agreed solution.

I have researched this question, but it was closed for not having a goal. My goal is to have more productive conversations with these individuals, while at the same time not conceding that code quality is an issue that should be taken seriously, and that others have valuable input. Additionally, I am not sure if my position is different being technically an outsider (consultant).

  • 3
    Time to look for a new job. This company will probably be going down the drain what with that attitude.
    – AndreiROM
    Commented Nov 17, 2017 at 19:26

3 Answers 3


If the manager doesn't value code quality and trust his developer judgement better than yours there is not much you can do. As a consultant you are not a decision maker so it's not your responsibility if good practices are not being followed, nonetheless keep record of all this interactions. Maybe writing a minute stating what was the decision taken by all parts so you have evidence when they do something different afterwards. You probably want to inform this problems to your hiring company so maybe they can guide you or try to solve this at a higher level. Also may help if you offer to coach Ted about some of the technical knowledge or good practices so he understands better your point in these discussions.


The managing developer alone has final say on what pull requests are merged. I will call him "Ted".

This is the issue. Ted is responsible for all pull requests. Why is a single person responsible for all merged code? It's a team effort, surely, so the team should have say on what code gets merged.

The solution is to use a process where two or more team members must approve code before it is merged.

It's pretty common practice that multiple team members must approve a merge/pull request in order for it to be accepted. In fact, it seems that your team is already using this policy but it's being bypassed by Dave and Ted.

Common VCS tools, like Gitlab for example, can enforce a multi-user approval process through the software itself. I'm sure most other VCS tools nowadays can enforce this as well. Ted might be willing to adopt this since it reduces his workload.

If it's not adopted... well, there's not really anything you can do. You're an external employee and they're going to do what they want, even if it's not what's best.


This is a tough one...I've seen it a million times (I work in software development).

Software development is though, and it takes managers with a combination of logic/mathematics and managerial skills, very rare birds.

Since many companies cannot afford to pay for this combination of skills, they go for next best, which is just logic/mathematics skills (i.e. take a developer and make him a manager) or just managerial skills (i.e. take any manager).

That puts unreasonable pressure on the person, because most developers simply do not have in them the assertiveness and people skills needed, and most managers do not have high enough IQ.

So in the first case development grinds to a halt, because managers try to reach consensus by endless talking and reasoning, and in the second case (your case I think) managers understand that the task is beyond them, and do exactly what you are describing.

I have never seen this end well or be fixed, so I would advise to either take it easy and ignore bad pull requests, or, if you care about good code etc., get a newer, better skill and move on to a better environment.

You must log in to answer this question.

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