Reducing coding standards 'brainwashing' duration and effort of new hires.

Question

At my current job we're pretty strict about code quality and coding standards. All new hires go through a 'brainwashing' period in which time senior developers coach them to write (hopefully) better code.

The code review process is meticulous and it normally halves the productivity of the developers doing the review. And sometimes the 'brainwashing' period drags on for 2 or 3 months. Sometimes corrections are subtle (e.g. structuring an IF statement so that it short circuits as early as possible) and sometimes you can't help but to raise an eyebrow (e.g. declare a string and set it to String.Empty and on the very next line assign it another value).

I'm looking for suggestions to reduce the time and effort to get new hires assimilated to coding standards of the team.

What are others doing in similar circumstances? What processes or tools are you guys using? Is there a way to automate this? I've considered FxCop but haven't actually tried it and don't know if it would really help reduce time and effort or if it is even the right tool? For logistical reasons we can't do pair programming if that was a suggestion. And I would be dubious about it reducing the effort.

We have tried maintaining an in-house wiki of 'corrections' but that is failing dismally. Lack of enforcement and also because it's easier to 'have someone correct your mistakes' rather then 'read up and try and prevent the mistakes'.

Also, how are you guys drilling it into new hires that code quality is important? And do you guys weed out those who are lackadaisical towards quality at the interview or do you try to change them after they're hired?

Many thanks.

EDIT: Thanks for all the answers. Not sure if there is a correct answer for this question but I'm going to mark as correct the one that I'll definitely be trying out.

Answer 1

I'm not sure if you have some of these in place, but they might be helpful.

• Training period for new hires - where they get oriented on anything and everything about your company, including a part on code standards.
• Penalties for not following the code standards - whether you have a "code standard violation pot" where they pay a fine for not following standards, or they have to treat you for lunch for every 10 or so violations. Of course, negative motivation doesn't always work
• Remove their commits that don't follow standards - not sure if all source control systems allow this but, if a coder commits non-compliant code, then that means that it has to go. No excuses.

Ultimately I think it the training is all you need though, the other two suggestions tend to border on fascist, I admit.

Answer 2

If you are that strict about your coding standards and you're doing all this work manually you could save time significantly by employing several automated tools. They will make the live of your senior developers so much easier (I assume you use .NET as you mentioned FxCop):

1. On the client side - you could use things like ReSharper R# with templates functionality to make sure that the code comply with your guidelines
2. On the server side - you need to setup a Continuous Integration system and integrate tools like FxCop into it. We use FxCop and compliment it with an product from our company called PBA which allows the same functionality.

Answer 3

Maybe it is not really related to what you asked but I just want to share with you guys:

Once my algorithm teacher saw that someone wears a T-Shirt writing on it:"No bug, good programmer!" Then he said "I don't think so. You must have bugs to be a good programmer." -It was an interesting point.

So, why don't you teach writing bugs? I am talking about using a reverse way to make people be a good programmer.

Answer 4

Spend some time writing an application that demonstrates all of your principles of optimal code. The source of this can be turned into a handbook on "What to aim for". People do much better at achieving a goal with concrete aims rather than continually being penalised by striking "anti-goals". Also it takes less time to point people in the right direction than to describe the right direction in terms of all the ones that are wrong.

Your optimal code primer project may also be deliberately suboptimised with common gotchas and poor algorithmic construction. Notes on the difference between the two may be inserted into the primer with hard facts about how one is demonstrably sub-optimal in comparison to the other.

It's not just newbies who can benefit from such an artifact, I myself am quite isolated in my job and rely on online coding communities for most of my professional development. Some clear cut examples of best practice that everyone could agree on would be of much interest to me.

Answer 5

1. Do a code standards training and have a reference document
2. Use a code style checking tool - even treat some style errors as build errors
3. Do code reviews on commits
   • Source control systems allow setting up hooks and commit queues, so no bad code goes to the main tree
4. A 'lessons-learned' and 'styling-tips' email sent to everyone from time to time wouldn't hurt. Sometimes the "why" of some guidelines is not obvious to everyone and thus hard to apply to, so such mail can even trigger a lunch/coffee discussion everyone can learn from.

Answer 6

I don't think you can reduce the length of the learning period, but you can reduce the amount of un-necessary work caused during it by having more frequent code reviews than you would for more experienced developers.

Start by giving the new starters some bugs to fix, and review each of their fixes as they have done it. An additional benefit of starting them off doing bug fixing should be that they'll be exposed to your existing code which you hope will meet your standards already (sadly too high a proportion of ours doesn't).