Develolper Expertize

Trivial principle ,yet usually ignored because lack of time in the short run.

Developers must have expertize in both the subject domain they are working on, whether it is finance/networking or music.
They should also have a minimal level of knowledge in the programming language they are using.
Sounds trivial? it is not. Most teams has at least one "novice" programmer strait from the university which, usually, don`t have the required expertise I mentioned. You can:

1. Let him code new features
2. Let him only fix old features
3. Let him watch but never touch production-code. He can touch non-critical scripts.
4. We do not hire inexperienced employees.
   

What happens in your team?
I bet most of you answer (2) , some answer (1) , know that it is bad but have tight deadlines and only small percentage will answer (3) , and almost no one answered (4).

What is the right answer? I have to go with (3) and in some cases even (4).
I think the best analogy to this questions , is a case where a father and son need to paint the house together.
Asking your 3-years old boy to help you paint the house is not helpfull. Yes , he is cute and eager to help , but we both know you can do it alone in half the time you will do it together , because you need to superwise him all the time , make sure he does not "eat the paint" and paint the furntiure.
When your kid is 10 years old you may start using him, knowing that although you will not save time yet, this will help your kid learn the craft.
When your kid is 12 , you still supervise him, but already gain a good time boost with his help.
When your kid is 15 , he can do the job himself , and if you work together , you get the job done in half the time.

Setting the analogy aside, you can can let your new employee write non-production code. This is either internal-company-code or even unit-test-code. At the first week or two , you probably won`t gain any time benefit from him doing that , but like the 10 years old kid , the developer learns the craft.
For those of you who answered (1) with tight-deadlines , please understand that it will only take you more time , in the medium-long run. What is code good for if it is written fast but does not pass first QA tests?
For those who answered (2) , another analogy: lets say you missed a very small spot when painting the cieling , will you give your 3-years old boy the brush and a ladder and let him loose? you will probably , again , loose time. Fixing bugs is not a good way to make new employees learn the craft. It is only the "easy" (not caring) way to do it.


Last emphasize , expertise of a new subject is needed even for an engineer with dozen years of experience. For example , multi-threading expertise is a hard and quite rare one.
Don`t let any programmer write multi-threaded code before s/he had a course/book in the matter and few weeks(months?) of experience with writing non-production multi-threaded code.