I’ve recently had the opportunity to both be the new person on a team and to integrate new team members onto a team that I had been a part of for a long time. Having seen it from both sides, I have some thoughts on how to join a new team without driving everyone crazy. It doesn’t matter how you became a member of the new team, everybody starts in the same place, which is to say, not really knowing the code base or the culture of the team. Learning to mesh well with the culture of a new team is almost certainly more difficult than learning to work in a new code base.
The first thing you have to do when you join a new team is check your ego at the door. It doesn’t matter how experienced you are or how many great ideas you have. At the beginning, your job is to be a sponge and learn as much as you possibly can. Just shut up and listen. Read anything you can get ahold of. Eavesdrop when other people are talking about the project. At the beginning, think of yourself as a spy — gathering as much information as you can without drawing too much attention to yourself. I even try to make it a point to try to figure out the answers to questions myself before I ask someone. The digging involved can be very educational, and showing some level of self-sufficiency will garner respect, at least until you make a big mistake that could have been avoided by asking a few simple questions.
One question I try to avoid until I get to the point of saying “our code” rather than “your code” is “Why?” Figuring out why things are done a certain way is important, but “Why?” is a question that can very easily come across as critical, especially when it comes from someone who’s not really trusted. The truth is that the stuff that makes you want to ask why often really is worthy of criticism. Just let it go until fixing it is as much your responsibility as it is anyone else’s.
The second important thing is to immerse yourself in the code style and coding habits of the team you’ve joined. Everybody who’s been programming for more than a month has their own opinion on whether to put spaces inside parentheses (doing so is crazy) or whether braces go at the end of the line or on the beginning of the next line. The team almost certainly has a policy on whether to use tabs or spaces when indenting. Beyond that, the team probably already has its own answers to more substantive questions about how their code is organized and how they deal with separation of concerns. At the beginning, do it all their way. If you have some ideas for improvement, propose them to the entire team once you’ve shown that you’re a team player. Coming in the door and writing code in your style rather than the team’s style is likely to infuriate at least one other member of the team. Furthermore, immersing yourself in the native culture is the best way to learn. People often have very good reasons for doing things the way that they do, and if you’re busy trying to impose your brilliant ideas on the team, you’ll never learn what those reasons are.
The third thing is to focus on service. Look for opportunities to be helpful wherever possible. The biggest mistake I ever made at a job was listening when the director of the group led us to believe that stuff other groups wanted from us was not as important as the things we were building for him. In the end, we had an unpleasantly dysfunctional workplace, and I found myself looking for another job.
The stakes are high. There are two ways things can play out, depending on the team dynamics. A new person who stomps all over the existing culture of the team will tend to be marginalized by the current members and will face a much tougher climb to build credibility. If the team feels confident in complaining to management about the new guy, they’ll in all likelihood try to get them disciplined or fired. If there’s something about the new guy that makes them seem untouchable (the usual scenario is that they were hired due to a prior relationship with the manager), then the current members of the team will leave. In the end, it all comes down to respect and you gain the respect of the team by treating the team with respect.
February 2, 2012 at 10:54 am
Good points all around that I agree with, with the exception of one. I would recommend asking why, even early on. Ask the question in such a way so as not to come off as condescending, but I think asking why goes to another point you made later in the post:
“People often have very good reasons for doing things the way that they do, and if you’re busy trying to impose your brilliant ideas on the team, you’ll never learn what those reasons are.”
Asking why can be one of the fastest ways to learn the good reasons for why things are being done the way they are. Knowing the reasons for why something was done helps you integrate into the team faster and become more productive. Asking why can also show that you’re inquisitive and want to help the team, much to your point about service.
It’s a spot on post that lays out good points that any new dev would be smart to follow.
February 2, 2012 at 11:27 am
The “why” thing is the toughest, because I always want to know why. On that one, I’d say at least give it a week or two. Write the questions down and ask them later. I just think it’s really, really hard to ask that question without making people defensive, especially if they don’t know you very well. Maybe you should wait to ask it until you’ve made a mistake that everybody else knows about.
February 2, 2012 at 12:04 pm
This is pretty good advice for entering all kinds of team and collaborative environments — I used to work in a lab, and post docs coming in full of themselves always ended floundering around for a while in a way they wouldn’t have had to if they were willing to learn from the folks who were already doing related work. Plus, it’s hard to shake opinions that people formed of you while fully resentful of your arrival. Better to become a student of the place and then, as you say, (1) save your suggestions for when you’ve established your credibility, and (2) gradually incorporate your preferences once you know your realm of freedom (i.e., where you can do things your way without interfering with the larger group’s functions).
I think that sometimes people make a bad entrance pricisely because they’re insecure about the new place and want to impress people, so that they lose track of the fact that establishing yourself as part of the team is at least as important, even if a lot of your work will be separate. Nobody has nothing to learn.
February 2, 2012 at 1:08 pm
Humility can ease the Whys; I begin each question with “I must be missing something…” or something of the sort. Always assume you are stupid or uninformed, and you’ll rarely offend anyone. Usually the answer is “I don’t know why we did it that way, do you have any suggestions?”
February 4, 2012 at 3:22 am
This is a great post. I think you’re spot on regarding the why question. I can’t believe how many times I’ve done this wrong.
February 7, 2012 at 4:47 pm
I think this is pretty much all spot-on except that there are occasions when “Why?” really needs to be asked. But minimizing those occasions is sensible. The other approach is to find the person on the team who likes answering your questions and knows the history of the project, and take them out to lunch a lot.
Restraining the impulse to describe the code as a steaming pile of poop is probably the hardest. New code is always incomprehensible and any application code that’s actually in use is probably a mess to some degree. You don’t understand the abstractions in use and the organization of control or the way execution flows. You’re an idiot, basically, and your opinion on the code is worthless. That’s a hard pill to swallow.
6 months in of course you’ll realize that everyone else thinks the code is a steaming pile of poop too, and then maybe you can even do something about it.