Dealing with co-workers who don't use best practices if you're the "new guy"

Question

I'm just wondering how you recommend to tackle working with other developers who don't follow best practices, especially when you are new to the team and job. Ideally you would find this out beforehand and not accept the job, I suppose, but sometimes you don't have that luxury and have to deal with the situation. My "people skills" are lacking a little and I don't know how to approach this without seeming arrogant.

For example, if you join a software team and find out that the team doesn't use source control (or don't use it properly), don't write tests, and don't apply things like the SOLID principles (SRP, OCP, LSP, ISP, DIP) to their code, how do you tackle this when you're the new/junior member of the team?

I ask this question because I've had a few experiences of this sort, and being someone who regularly reads blogs and watches screencasts highlighting best practices I've found that I can't bring myself to "dumb down" my development skills and just go with the flow that everyone else does (e.g. putting business logic in ASPX code behind files, or worse mixing logic and presentation), however since invariably this happens when I'm brand new to a team, I'm not sure how to convince everyone else to do it without coming off as a jerk and/or know-it-all.

How would you approach this situation, where you being the newbie know more about best practices than the other experienced members of your team?

Answer 1

You could ask them, for instance, what they think about the SOLID principle.

I don't think they will take it as arrogant if you ask them and they might even change their habits when they realize that it is a good thing to do.

It is usually better, ie. more convincing, if they find out by themselves.

Answer 2

Discuss it with your manager first?

Maybe you were hired because you know about these things, and they want you to help the team to pick them up and use them.

Also, most people don't like being told they are wrong, so make suggestions such as "have you thought about doing X for this", etc.

Answer 3

I've been in this type of situation before. You want to make sure you don't alienate any of the people on your team by telling they have to use a certain technology or that they are doing everything wrong. Also, don't assume you know everything about the project on your first day. Take some time to ask questions of the senior techies around the project and see how it is they do things. Ask question about, like you mentioned, source control, issue tracking, continuous integration, etc. Let them know you're thinking about it and that you're on the front edge of this kind of thing without seeming arrogant.

When you've been there about a month, after you've established that you know what you're doing, introduce a demonstration of these technologies to either the senior tech person or the project manager, depending on who you think will be more receptive to the ideas. Make sure you're demonstration is targeted at their type of development, which you can do because you spent the last month learning how they do things. Just be open to other peoples ways of doing things, and try to get people on board as you can.

Answer 4

You need to listen to experienced members of your team.

You can learn much from them. You don't need to say much about the best practices.

Just make one or two suggestions in each meeting. Your senior will think whether your suggestions are feasible or not. Your suggestions may work sometimes, but sometimes may not work because of some limitations.

Answer 5

When you spot something you don't agree with, ask them why they do it the way they do it. Have a conversation. That's most likely to bring out the best outcome for both parties.

Answer 6

If you don't know the people well, don't assume you are better than them. If you are new to a place and you see them doing things differently, don't assume that it is wrong. The best thing to do when you are new is to shut up about your opinion and listen to others. Most people hate being corrected, especially by someone they don't know very well. Instead of telling them what they are doing wrong, try to earn a bit of respect first, by showing that you know what your talking about.

It is easy to come into a new setting and claiming they are doing things wrong. In most situations there isn't a clear cut right way to do things, even with source control, test driven development and working methods. Don't assume you are right. Try to listen to them, and maybe you will learn something new instead.

I've experienced people who are new to an organization I've been in for a long time go around and point out how everyone else is doing something wrong, or how they don't follow the correct standards for that kind of work. At the same time they fail to produce anything of real value, although the work they produce follows all the right standards. At the same time I've experienced newbies who don't follow any of the standards whip out incredibly useful work in very short time. Although I don't agree with the method they used, their applications does what is needed. Most of the time the way you do stuff isn't important.

Answer 7

Introduce these techniques one by one. The best way will be to email your team mates these screencasts. They will find it good and ask you to introduce the practices in the project.

Answer 8

• Do what you know is best. Demonstrate best practices through your own actions.

• Be open to the idea that the other guys maybe know something. Ask them to explain how they deal with certain classes of problems. Ask along the lines of "is better than ? How does it work ?" etc.

• Start weekly tech-talks. Present ideas for how to do things. Remember not only your favorite processes, but also A TRANSITION PLAN -- how will the team transition from what they're doing now to what you think they should be doing? What are the benefits? What about all that extra process? How will anyone have time to do all that? Etc. Anticipate objections, present solutions.

Luck!

Answer 9

Practice what you preach.

Use your own SVN (with turtoise you can have a repository on your own PC). The next time someone asks, what you have done two weeks ago, show him some SVN log.

Use SOLID principles in code pieces where you have the main responsibility (applying it to foreign code, might be too controversial). If someone needs changes, let him know how easy that would be. By the time people might get interested what you are talking about or might notice the stability of your code.

Discussing in depth LSP with someone who doesn't follow (or worser: doesn't like to follow) best practices is senseless. Show him on some real code. Show it in action.

Shine in what you are doing and discuss a little. Too much discussion might let you look arrogant. Don't be hasty. Whatevery you practice, do it throughly. You are representing the best practices out there ... so every piece of best practice you are introducing, must be a full success.

Answer 10

I usually kick back and keep relatively quiet for at least the first ~6 months. I signed on to a temporary position a while back and it was just like you described.

After a few weeks, I suggested using a VCS/DVCS ... the idea did not go over very well. So, I started keeping a HG repo on my machine and just committing locally as things changed for my own sanity when finding regressions.

About six months passed and the team lead saw me working with Mercurial. I simply said "I hope you don't mind, I'm just clinging to this like a blanket because it helps me spot regressions sooner".

Low and behold, it wasn't the idea of bringing in a DVCS that was the problem, it was people wondering if I'd be around past the 90 day probationary period .. nobody wanted to change if all of the changes went out the window if I didn't last long.

So, needless to say, not only did we start using HG, we had six months worth of revision logs that helped weed out some issues.

It takes a bit of biting your lip to keep a low profile until people get used to you, but its really worth doing so. Once you can introduce one good practice that makes life easier for everyone, the rest come quickly.

Now (finally) we're also doing unit tests, nightly builds, etc.

Answer 11

Accept that you are the new guy and that there is a lot of inertia to overcome. Make stone soup. Introduce a small thing here and there, and try allow your coworkers to discover the benefits on their own. Provide friendly nudges in the right direction. It can be a rewarding project to see your colleagues grow and develop, if you're up to the challenge. Avoid coming out as a guy with a lot of criticism but no experience of the company. Sometimes you may discover that there is a reason things are done the way they are, and it may not have anything to do with the competence of your coworkers. If you criticize them for it, they may take it as a personal offense.

Answer 12

Joel Spolsky has a pretty pertinant article entitled, "Getting Things Done When You're Only A Grunt".

Discusses how a lowly programmer can instill change in an organization from within, with no official power.

Answer 13

Assuming that the original team was not completely dysfunctional, if they've been there for a while, they must have some expertise. And although, they may not be up-to-date on the latest and greatest technical or development practices, they are probably very knowledgeable about the business domain, the product space and the operational environment.

You don't have to use the latest technology, or practices to be good (or even great), you just have to know what you're doing and be able to deliver it consistently dead-line after dead-line.

I can remember joining a project when I was a junior and the coding standard was extremely esoteric (even way back then we had some standards). At first I thought that was horrible, but on reflection I learned that the code was (reasonably) solid, well-supported in operations, and consistent. But more importantly it was highly functional and really solved the user's problems. A decade later, after a couple of failed rewrites, the system that did replace it (because it was tied to VMS), had only a fraction of the functionality and spent a long time being really flaky. The sad part: the replacement system was built with the best practices of its day, yet it was far worse.

The point is that you're picking on a very limited area on which to base your judgments, hopefully there is a great amount of good stuff to learn as well. The newbie almost never knows more than the existing team, unless he's just jumped ship from leading the competitor's project. It's not all about code or how you assemble it.

And, a good team will naturally absorb the new stuff that is brought in by the newbie, often that's the point of hiring somebody new. You want to get them to add to the existing pool of knowledge as "young blood", or "a fresh pair of eyes". Either way, in time, all newbies make their mark, its just that people change slowly, and like to change slowly. Prove yourself, learn, share, pick your battles, look on the bright side and gradually help to craft the project into something better.

Answer 14

I find the way around this is to build up rep by being generally good at things and work on a "WTF?" look that you can pull whenever you hear about the fact they don't use Source Control or whatever. Follow that up with a few points about the benefits it would bring but pursue it no further.

After you've built your rep at the company they'll be more likely to adopt your ideas or come to you for guidance. Just don't be impatient. It takes time for people to work these things out.

The most important thing to remember is that you can build quality software without following best practice, this is what a lot of people seem to have forgotten. Best practice certainly helps and makes the process easier but by no means impossible. Even though you know ways to make things easier you're just going to have to (in the short term at least) bite your tongue and do things the more difficult way.

Answer 15

It might be smart to lead by example. Just because everyone doesn't use the SOLID principles, etc, doesn't mean you shouldn't.

Answer 16

As a totally new guy I don't think I would have said anything to my co-workers until they actually showed some interest or asked about certain techniques or tools. It is incredibly easy to alienate yourself towards co-workers if they get the feeling you are trying to lecture them.

As most people here have said the most important thing is to practice what (or perhaps before) you preach. Hopefully people will start noticing and ask questions about why you do things in certain ways, and then you are in a perfect situation for lecturing them in a non-intrusive way.

If you are in a situation where you feel you really have to correct someone, choosing the right words will also get you far. Instead of shouting out: "Hey, you can't do it like that!", try with something like: "Can I show you something?", and then go on by giving an example of what kind of trouble they can avoid by doing it your way.

You say your people skills are lacking a little, but I think that just by asking this question and realizing that you have to be sensitive about the way you approach other peoples developing "traditions", shows quite the opposite. If you use your gut feeling (and are to able to tell when you are trying to show off versus actually giving good advice), and make sure you have good examples at hand, I'm sure you will be a well respected co-worker that helps productivity.