Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have just started a new job and all is not well in neverland. I had high hopes for this company, but when I arrived, I walked into a team that I am having a hard time working with... The two existing developers on this project are having a hard time accepting any suggestions or changes to the code that they spent the last few months writing.

It seems like a political minefield and so far their way of dealing with a new team member has been to avoid explaining as much as possible. example: this is a rewrite of an existing system and apparently I don't need to know anything about the old system because they have already reviewed it and know what needs to be done.

I don't want to make this a long rant, but there are other issues including micro-management, assigning only trivial bug fixes, and an unwillingness to consider any suggestion, idea, or minor code change that is a departure from how it is currently written. Example: I had a bug fix to make sure a search screen truncated names longer than 25 characters. One of the existing developers made the comment that I need to talk to them before I start so he can show me how the existing string truncate is done, LOL. If I check in code without consulting them first then "the team" decides that it needs to be reworked.

HOW do I deal with this? Has anyone out there ever overcome similar issues? Is this just a lost cause???

P.S. I'm not a junior level or incompetent programmer. I'm no rock star, but I've got as much experience and knowledge as the rest of my team, so I don't think that is the underlying issue.


migration rejected from May 25 at 19:32

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by durron597, MichaelT, Ixrec, Robert Harvey, amon May 25 at 19:32

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – durron597, MichaelT, Ixrec, Robert Harvey, amon
If this question can be reworded to fit the rules in the help center, please edit the question.

It's good to be patient as others suggested, but first impressions are often amazingly accurate. Trust yourself. If something doesn't feel right, don't ignore it too long. It's like the common advice about marriage - marriage is hard work and you should work hard at it. That makes sense if you've invested 20 years in the relationship. But if something doesn't feel right and you need counseling before the wedding, just cut your losses and leave. – Corbin March Apr 6 '11 at 20:09
Oh my god, I have gone through this before. I've been treated like this even after two years on the job! I think people are just jealous, or dislike personalities, so they go out of their way to act stupid. – Rick Ratayczak Mar 24 '13 at 10:59

6 Answers 6

up vote 5 down vote accepted

I think there may be faults on both sides.

It's standard practise for new developers to be assigned "trivial bug fixes" to start with, and review their code, so they can prove themselves. After you have proved yourself like this, then you will get a better hearing for suggestions for new ways of working. Even then, be humble & be willing to hear the advantages of the old way.

If the senior developers are really "avoiding explaining as much as possible" that's bad. They should be helping you learn. You could ask if there's any technical documentation you can read - if not, offer to write some! That's a great way to learn. But be sensitive to the needs of the business - don't suggest this when you're desperately trying to get out a critical release or bug fix.

I don't take anything you said personally :) in fact I wish that my coworkers had spoken to me as candidly – nick Apr 8 '11 at 5:10
Actually "not taking anything personally" is another very good principle! – MarkJ Apr 8 '11 at 8:05

Sounds to me like you need to fit in with their way of working a bit more, give them a chance. You are the new guy, it's up to you to fit in I'm afraid.

The guy offered to show you how the string truncate worked, but you seemed to just ignore him. Sounds to me that this was a chance to work with them and get to know them and discover what their issues and concerns were (edit in light of comments: even if the code he was showing you was trivial it is still an opportunity to build some communication and trust with the team, or at least an individual).

You also checked in code without checking with them first. I never do this regardless of how well I know the product or the team, all code is reviewed and any new guy should especially be seeking to have code reviewed.

You need to earn their trust, it's not automatic, regardless of your level of skill or experience. It might suck, but that's how most tight-knit teams work.

PS. Please do not take any part of my answer personally. It sounds like you are in a very tough position and your new team is being less than welcoming and I do symapthise with you. Your new colleagues should go out of the way to welcome you and help you settle in, but it sounds like they are not, this is very unfair and is making your life very hard. The chances are that in a few weeks you'll be on the right side of these guys and all this will be forgotten, but it takes time to join a team and you have to play along to some extent.

I'm going to have to disagree with code reviewing everything. The string truncate example boils down to this: return value.Length > 15 ? value.Substring(0, 15) + "..." : value; I changed it to return value.Length > 20 ? value.Substring(0, 20) + "..." : value; That doesn't need a code review and I was able to find the constant all by myself thank you very much. With that being said, I appreciate your candid comments and there is probably a lot of truth in it (string truncation not withstanding). – nick Apr 6 '11 at 16:43
@nick - no matter how trivial the commit, or how senior the developer, I would expect to review everything for a while. As trust is built, larger and larger things may go unreviewed. A senior person should climb this faster, but if they bristle against it, then our interviewing messed up, they are too touchy and not right for our company. – sdg Apr 6 '11 at 17:02
I stand by my comment. everything gets code reviewed prior to check in. No exceptions, except for fixing a broken build which still gets a code review but can be done after check in. – Steve Haigh Apr 6 '11 at 20:38
And, by the way, if I reviewed that code I would have comments :-). You seem to have space for 23 chars because 20 chars + "..." appears to be OK, so why truncate a 21 to 23 char string? – Steve Haigh Apr 6 '11 at 20:55
I don't take anything you said personally :) If only my coworkers had spoken to me as candidly... – nick Apr 8 '11 at 5:12

They need to know you're not a threat

I've dealt with crippled personalities in the business, "childish and territorial." They're not bad people, and management probably shares the blame. They need to know you're not a threat.

Let them explain string truncation until they're blue in the face, and they'll no longer see you as a threat. Remember friendship; conversations about favorite video games, eating junk food together, doing some OT with the crew.

They now know you're cool (not a threat or some moron). After you're in, you can have mourning meetings and come to a solution together. I've seen it work.


I too have recently started working on a team in a new company. It can be hard, especially if you were used to being respected and considered knowledgeable in your last role.

Here is what I did:

For the first 3 weeks, I was deliberately verifying nearly all my actions, and reviewing all my changes with team mates before committing them to source control. I was asking questions to understand their existing working practices, and how I needed to interact with them and so on... over time, each of the team members started saying things like "yeah, you have got the right idea" and so on.

I've been there 5 weeks. The fellow team mates have seen and reviewed lots of my decisions, and now they have confidence in me. There are already times when they are asking me for advice.

Its not always easy being the new boy. You will be doing lots of bug fixing at first. (its a good way to find out about a lot of existing code) and you will have to earn your new work mates respect. At the end of the day, developing is usually a team effort, and to do your job you need to be part of the team. Standing at the side and saying that your new workmates previous work is of a poor standard will not make you many friends, and will probably lessen the value attached to what you say about other issues too.

Perhaps it has deteriorated too far at this job, and you will need to move on, but you can try to be helpful and see if that builds you respect.


Now that you have seen the code, is it good or bad? If the code is really poor, and the poor quality is imperceptible to your colleagues, then I would be looking for another position. I will not tiptoe around in bad code for any length of time or any amount of money. There are better uses for my life. Besides, organizations with bad code usually don't pay well.


I say ask management what your role is meant to be in the team, and if you don't like it, tell him it's not what you signed up for and leave.

If he tells you he's trying to use you to "fix" the other two, tell him it's not working, and offer to leave.

If he still wants you to stay, then tell him he needs to meet with the other two guys and make it plain to them that you will be bonuses and raises are dependent on the team reaching management goals, and no other way.

Looks like, though, that you will be out looking for another job soon.


Not the answer you're looking for? Browse other questions tagged or ask your own question.