How forgiving do you need to be on new employees?

Question

Recently we have a new developer in our team. We are getting him up to speed and he is picking it all up quite fast, but a new developer means new (foreign) coding styles and ways to solve things.

It feels kinda petty to start whining about coding styles at the first three classes he codes, but how forgiving are you guys when dealing with new developers? Do you let them muddle on, and point it out later? Or do you wield the scepter of intolerance immediately?

When do you draw the line, or if not, why not?

P.S. New guy, if you read this: you are doing great, keep up the good work ;)

Edit:

I've accepted the most up-voted answer, as most answers share the same message: Be nice, but tell them asap!

Answer 1

As a relatively new employee at my current company (less than 6 months), I'll just point out that I always prefer to be told of things like this ASAP rather than later. If I don't know that I'm doing something wrong, I'm going to continue doing it wrong and it's going to probably cause more work for others involved in the project. I don't want my team leader to have to code-review everything I write just so that he can make sure I'm following the proper formatting guidelines.

If you point out the inconsistencies with the style guide in a polite and reasonable manner, I don't think you'll hurt anybody's feelings. I know I certainly don't take criticism of that nature personally as long as it's presented in a way that isn't blatantly offensive. Be understanding of the fact that transition is tough - and make sure your employees can tell that you're understanding - but don't just ignore it altogether. I'm sure I speak for most new hires when I say that we want to contribute to the team the right way, but sometimes we just fall into old habits in the beginning (or forget more nuanced style restrictions).

So in a nutshell: I'd say be positive, but don't look the other way. Most new guys really want to learn, so there's no reason not to take the opportunity to teach!

Answer 2

The longer you go letting him use his coding style the more code there will be to fix. I'd tell him/her as soon as possible.

Just make sure to make it non-personal... "This is our standard, please follow it" kind of thing. And keep in mind that this new person is going through a lot right now, new team, new projects and may not even notice that the code all conforms to a coding style.

Answer 3

You can tell them what they are doing wrong without being a jerk about it. The most important part is that they guy is picking up what he needs to pick up. Development is a team effort, and code styles are just one of the ways that teams cooperate. There is no "one" way that is higher and mightier than other ways. It's just that a team needs to know what to expect when they dive into code they haven't seen before. My current job handed me the coding standard right away, as it was nicely written up and I had to do something while I was waiting for the paperwork process to complete.

The sandwich method of delivering criticism is predictable, but it works. Essentially, you tell the person their doing a good job (be specific), there's some minor things we do differently, and then follow up with "but I really like what I see here". Most of us are professionals, and we can deal with the fact that there are different ways of formatting code. I've been on both ends of that conversation. It's usually never confrontational. It's simply the fact that we do things a little different than you are used to.

Edit

I used to do martial arts, and part of being an upper belt is teaching lower belts how to do things in this particualr martial arts style. I may see several different things wrong the under belt is doing with their punch, but instead of overwhelming them with the littany of criticism I give them the top one or two things to work on at a time. Once they've got that working, I move on to the next thing.

If the coding style the new guy is using is vastly different from your team style, you can use that approach to get them in step quickly without making a federal case out of it.

Answer 4

Getting things right from the beginning is going to save a lot of problems later on as otherwise someone is going to have to go through the code again to bring it in line with your standards.

Praise the work that's correct but use the code review as a means of introducing and learning about your coding standards and styles.

Most developers will be happy to work to the house style - as long as they know what that style is.

Answer 5

If coding style is the only issue here, then the solution is to have a written document describing the coding guidelines, and to give it to the new employee to read on his first day on the job.

The coding guidelines document should clearly specify what is considered mandatory (e.g. you must have include guards, use CamelCase, begin class names with capital letters, and prefix data members with m_), and what variations in personal style are acceptable (e. g. how you use spaces in an if statements: if(condition) or if (condition)). Or you can simply say that whatever is not explicitly specified in the document is left up to the individual.

Furthermore, the guidelines must be enforced during code reviews.

This way your new employee knows what is expected up front, and the whole thing becomes a non-issue. Otherwise, if you do not have clear written guidelines or code reviews to enforce them (and to find bugs too), then you are setting yourself up for an awkward situation.

Answer 6

Inconsistent coding style can litter your code base if you allow this to go on. While I would be tolerant with the matter, point out the issue to him and have him revise the offending classes.

Also, if you haven't already, set up a formal coding-standards reference that is a manditory read for new developers.

Edit

I can say that I have, in the last 6 months, written code that does not conform to my employers coding-standards. There is a particular class that is now widely used that uses CamelCase rather that delimited_case for variables and properties; I wish I had realized I did this earlier.

Answer 7

Personally, I think that if you are going to the exceptional expense of taking on a new staff member, then it is worth spending some initial time training them in "the way we do things here".

As the senior coder, if there is a new team member then I tend to spend a few days with them one-to-one when they first turn up. This gives time to carefully show code style, not just syntactic and layout, but the default choices of approach the team favours, the lowdown on any internal frameworks that are in use, documentation style, etc.

New employees want to make a good impression, they also are terrified usually of appearing lost, or asking stupid questions. Spending this initial time with them, intensively training them in "the way" within your organisation disspells this. Additionally it is an excellent way to get to know the new staff member well, which makes them feel much more a part of the team and indeed for the team to view them that way.

The only potential drawback is stifling potential new methods coming in that may benefit the organisation. This can be handled via encouragement to question methods of working were they have something better, with guidance as to why certain decisions are the way they are - often the prevailing style is not quite right, but refactoring is not an immediate option for some reason.

In summary: Train them from the outset, do not let them fumble about in the dark.

Answer 8

As a reletively new developer myself, I would like to be told what I am doing wrong or what I could be doing better. If there is a coding standard at the company, I'd expect to be held to it. However, I'd prefer if the people pointing out my mistakes (whether in procedure or code) would do it in such a way that I don't feel that "He should have known that, even though no one told him" attitude.

That being said, different people will respond better in different ways. I'm sure some respond to extremely strict "get it right the first time" rules, but I think most will develop best when guided to the best solution, even if it takes a few tries.

EDIT: And there is a term every new developer should learn: REFACTOR!

Answer 9

I learned when teaching that it is always better psychologically to start off with some hard rules and ease up later than to let someone think they are doing fine and have to tighten up the rules later. If you let someone go down the wrong path for a long time, it is much harder for them to grasp why it was OK last week but not now and they will fight the change that much harder.

The new employee should be given the coding standards not expected to figure them out for himself.

The manager of the employee should ask to see code as soon as possible - don't wait months before you ask to see it and should do a really picky code review. Explain what he should have done differently (and why) and then (and this is important) make him fix the problems before he is asked to work on anything else.

Do this several times inthe first month and you will find you have a developer who understands and follows your standard or you have a cowboy programmer who doesn't care what the company expects, he wants to do his thing in his way and damn the team. This guy needs to be fired as soon as possible because he will do more harm than not follow coding standards - he will program a HASKELL solution in a .net shop not because it is the best solution for the problem but just because he wants to learn HASKELL and no one else on the team can support it; he will add extra functionality the client doesn't want just because he thinks it's cool; he will refuse to do what the requirements ask for because they are using boring technology or he doesn't see the need; he will take working code and break it trying to make a change no one wanted him to make; he will fail to commit critical code to source control so no one else can touch it and on and on and on.

Answer 10

I always wield the scepter of intolerance; I'm just somewhat nicer about it with new developers. Coding standards and good programming style should not be optional, but you can use reviews for new developers as a teaching opportunity rather than simply shouting "FALE!".

Answer 11

I'm guessing that you don't have a style guide. You should probably write one up and give it to everyone, including your veteran devs. You wouldn't risk hurting the new dev's feelings that way either, since you wouldn't be singling him out.

Lots of examples on Google: http://www.google.com/search?hl=en&source=hp&q=coding+style+guide&btnG=Google+Search

Answer 12

Depends on how important it is to you.

It might be discussed as part of a pair programming session where his mentor teach him how you do it in your place.

Also, make the coding style automatic. We use the "reformat at each save" facility in Eclipse, so the layout comes automatically and fixes most but the naming schemes.

Answer 13

I think it's fairest to start early and he's likely to be more responsive at that point when he's keen to impress.

You just need to do it politely and to be open to any new ideas he has that you might want to take on board (after all, you presumably recruited him because he knows some stuff right and I'm hoping you don't think you know it all...)?

Answer 14

I prefer the correction sooner rather than later school myself. The approach though is key to my mind as you have to be careful in how to find the line of being assertive about the standards and why they are so important. Be clear on what was incorrect, be prepared to discuss this and understand what are the lines in terms of remedying the situation. To take your example a step further, do you have suggested name that would be better or is it just that what was used doesn't "feel right"? That latter is rather vague and annoying to my mind as it could seem like I'm being asked to mind read which I don't do. Instead, if you could say that the name should be shorter so that it isn't confusing then I can know what kind of metric to use in trying to rename things. Find things to praise in the work so that you can sandwich the changes you want between a couple of compliments. Sample if you like the tests and method lengths but not the length of the name: "Those were some great tests you wrote but could you rename this class to something shorter? Lastly, the methods seemed to be short and sweet just like we want thanks!" This can go over well as while you are asking for one thing, you are giving some compliments that may encourage the new developer to keep up the fine reputation you are giving them.

Answer 15

If it's simple formatting, use a modern IDE that auto formats OR run a commit hook on our source control tool.

If it's different implementations, document which way is acceptable in what situations. An example is using an iterator on a java collection versus a counter to walk a List. Either way "works", but there are subtle implications of one version versus the other.

Teachable moments are important.

Answer 16

Very good question. You seem to be asking mostly about those things that you need to train in house. In other words, you have a good programmer, who needs to be trained in the in house style. Style is not something you can expect a new programmer to know. It can only be developed with intense supervision.

From the question, he appears to have completed several tasks successfully from a functional point of view, but not from a stylistic point of view. At this stage, you need to jump in.

Do not assign him any new tasks. His primary task from now on should be to refactor the code to the in-house style. I picture the conversation going like this: "I'm pleased with your performance. It is obvious that you have a good grasp of the code. The next step is to get you up to speed on the in-house style. What I'd like you to do this week is to redo the last few tasks and make them conform. To whit, your naming conventions, while perfectly acceptable in the large, do not conform to our style. Also, we prefer X bracketing style over Y. I'd like you to start with Class Q, and I'm assigning Programmer B to mentor you in this task. Come see me when it's done, and we'll go over the code line by line. This may take a while, but it's like riding a bicycle, and we'll get you up to speed soon."

Answer 17

Often this is a good time to examine how much of your established guidelines still fit the possibilities of the toolset/language. New guys will make it very obvious where you have been neglecting a possibility if they are very good.

Assuming you have done that, Tell him ASAP, Have someone pair with him or do reviews very, very often so he does not waste time writing code you are not going to accept for a style reason.

Answer 18

Anticipation is the key !

I started working in my former company two years ago. One of the most frustrating thing was getting insufficient or no information, doing things your way and learning afterwards that definitely : "No, here we work differently".

Here are two ways I used to address this issue (there may be many others !) :

• Formal approach : as a general rule I recommend having an up-to-date and clear "welcome doc" giving useful information and making your expectations clear without having to repeat yourself each time a new colleague comes.

  A wiki could be a good way to do this (what I later set up in my company). It also allows you to improve your own internal rules with new ideas if you want. Make sure to place it close to whatever daily accessed resource otherwise it won't be used !

  I know that complaining about bad results is so much easier than making your expectations clear in the first place but it's worth doing it : mistakes can still be avoided, you're not in a faulty employee/sad boss relation. I find this more efficient and also more pleasant.

• Informal approach : talk to your colleagues, be curious, ask how things are done, etc. Well, communicate !

And if some issue eventually arises, better don't wait if you can !

Answer 19

Giving good feedback is really important, especially if coding style is bothering you and the rest of the team. Being able to effectively tell your new guy how you expect him to code is important.

Often, it's much easier and more long lasting to SHOW new people what to do. I find this is best accomplished by a week or two of pair programming with someone on your team who embodies your standards and practices.

You can point out when they don't follow your coding standards and write a document, but I've found pairing to be the most effective way to quickly install methodology or style in new hires.

Answer 20

I usually stick to the Zend coding standards whether I'm working with Zend or not. if your team also uses a well known & pretty much favoured coding standard such as Zend, then it's likely your new employees will not need much coaching.

it maybe worth reviewing your own standards if every new employee requires coaching & going by the Zend standards.

personally, i hate tabs in code. I prefer spaces (like Zend) for indents etc.