Suggestions wanted on dealing with hyper territorial team

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

It sounds like management aren't doing their job properly. If the managers aren't encouraging an environment conducive to productive and enabled work, they're doing it wrong.

Speak to the manager(s) about your concerns, try not to make it too personal and make sure you have your opinions heard. Failing that, start looking for another job.

I've worked in teams like this before, even on Open Source projects. One such example is a team where I asked if I could modify some of the comments and submit patches because they were written in broken English. Rather than relish the idea of someone making the comments clearer for new developers, they reacted defensively and with great hostility. And that was just about changing comments. Heaven knows how they would've reacted had I submitted a patch that actually changed code!

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.