views:

190

answers:

5

Suppose circumstances cause you to be transferred to a new team of programmers. This can happen for example because you are assigned to a new project within the same company, or after changing jobs. After a while you begin to realize that your new team members have very bad programming habits: there code contains a lot of duplication, is documented very badly, they program at low levels of abstraction, code never gets refactored, etc...This existing team counts more than say three members, meaning you are a considerable minority with your totally different style of coding.

My question is: what can you do when you find yourself in such a situation? Do you try to reeducate your team members? Or do you go your own way, often causing severe clashes? Or do you adapt, leaving your - in your opinion better - programming style behind? Or do you simply look for another job?

+8  A: 

This joelonsoftware blog must give you a very good idea

Getting Things Done When You're Only a Grunt

http://www.joelonsoftware.com/articles/fog0000000332.html

ckv
Great link. Thanks!
Dimitri C.
+2  A: 

Do the things the way you're used to, and when another team member asks you why you did something some way explain him why. If you're right you'll be respected by the other team members and your style will begin to be adopted. Also, make sure your boss notices you're the "man to ask" in the team.

:)

manolowar
+1  A: 

Some coding styles are better than another; removing duplication is almost always good, for example. Others are much more subjective; don't argue over tabs or spaces, just match what the application already uses.

For changing away from styles that are objectively bad, never force conflict, because you're not going to win; approaching it aggressively will not get the other developers to willingly change their style, and will occasionally convince them to dig in deeper.

You show them a better way. Sometimes they'll get it, and sometimes they won't. If the team - or team lead - see value in your way, get them to adopt it as "the way things are".

If they don't get it, find a new team.

Dean J
+2  A: 

The one thing I've learned is don't force it. Be patient and wait for the right time to make suggestions. It very much depends on your team's attitude towards change. This is more like fishing than hunting. But, even when they are willing to change it's still extremely hard to teach an old dog new tricks.

I think it's important to get in there and do it their way for a while. This gives you time to build trust and it gives you time to get to know who might be with you and who is going to be against you. You might find out if this has been tried before, and what happened. "Hey have you guys tried unit testing?" "Yea John Barleycorn, he used to work here, tried that. Steve ran him off. Great guy though." Those kinds of exchanges might help you define how long you going to try this experiment.

During this period, carefully note things you see you want to change. I suggest keeping a written record. The key part here is to build trust between you and fellow team members. So they recognize you as someone who knows what you're talking about. Then when they know you start making small suggestions on things that could be improved.

Go for small wins. Don't try and convert them away from using Singletons over night that's too big a battle, adopt unit testing across the code base, way too big. Stay away from things that require huge refactorings. If you suggest it don't be surprised when you're the only one doing the heavy lifting. Try things like cruise control if they aren't doing continuous integration, clean up the build process, or small refactorings that remove duplication.

If they are willing to make some changes then education might help, but you run the risk of coming off as being the know-it-all and alienating yourself. I think it's best to approach it as if the topic you want to discuss is pure academic interest unrelated to the team's work. Sort of like "Let's get together over lunch and just talk about interesting topics." Prepare a topic, and do a presentation. Pitch it as no one has to commit to it we're just learning about new things. Then see what the group's reaction is to that. Encourage discussion, and see if they talk about it outside of the meeting. If someone initiates another discussion with you that could be a good sign. It also could mean someone is a control freak and finds your ideas harmful to their own ideas. You just have to gauge the discussion that follows. If it's positive reaction then you might be able to win some people over.

Having people like you goes way further than knowing more than them. Just think about the best salesmen you know. I bet you liked him before you liked his product. Your a salesmen.

Then if all of that fails you have two choices. Wait till the lead moves on, and you can take their spot. Leads have powerful sway over the attitudes of the team, and what teams are willing to do and not do. Or get out of there and find a team that you find more suits your attitude.

chubbard
+1  A: 

I think the same principle applies whether you are the most junior or senior person in the team: lead from the front.

The reason that you think your way is better is because you understand the underlying principles and have some practical examples to explain why the more disciplined way is better. Explain explain explain why things should be done better. The more you try and explain it the better you will be at explaining it and convincing the team to do it better.

If the team has a leader who is allowing this to happen, explain to him or her in terms that show how they personally will benefit. If that person already agrees with you but can't influence the team then the team deserves a better leader. The same applies if the team leader just doesn't care. If the team has no leader, then it needs one and who better than someone who cares about standards.

Lastly you asked should you change to match their approach? No. Ultimately discipline has more lifetime reward (cash, joy, benefits) than indiscipline. Teams like this can look good because they deliver fast ... into failing organisations. Take the long view and stick your guns.

Good luck!

dwarFish