I've got a senior developer with eight years of .NET experience starting tomorrow to work on a 11,000-lines-of-code application. In the team there's myself and another programmer. We've both got about three years experience each.
It's my first project as a manager (I'm also a developer on the project) and this is the first time I've ever had to introduce someone to an already established code base. Obviously I'll be going over each module, the deployment process, etc., and handing them the location of the source control repository, documentation (which isn't the best), etc.
How long should I give them before they're ready to start writing new features and fixing bugs?
Best Answer
I would assign a couple of low priority bugs the first day, that way no one is screaming if they aren't done right away giving the new developer some time to get familiar with the code base.
The most critical thing to do is to have a code review of all of his work the first couple of weeks. You don't want to find out that the guy is going in the wrong direction or not following company coding standards months into things. It is better to make sure he knows what is expected from the start, and code reviews ensures this. Of course I think code reviews are good for all employees (We review 100% of our code before deployment), but they are critical for new employees and should be done in person where you can answer questions and refer them to documentation they may not have seen yet if need be.
What you don't want is a new guy coming in and using a different style from the rest of you. People often try to keep using the code style of their previous job even when it conflicts with the code style used at the new place which can create confusion and annoyance on the part of the other developers.
One thing I have noticed even with experienced developers is that some of them are not as good as they seemed to be in the interview, code review will help you find this out fast, so you can fix it. It will also encourage them to actually get something done, I have seen new employees who are not code reviewed drag out a project without showing what they were doing to anybody and then leave a week before the deadline they knew they were not going to hit because they were in over their heads and had not actually completed any part of the project. Better to check early and often with new people until you are really sure that they are working out.
Also, it is normal for the new guy to be appalled at the state of your legacy project. It's not designed the way he thinks it should have been. Expect this, hear him out and don't automatically dismiss everything he says. In particular, this person appears to have more experience than you or the other developers, he may see things you hadn't considered. However, as a manager, you have to balance the proposed changes against the current workload and deadlines. You all may want to invest some time in learning how to refactor existing code and invest some hours in your time estimates to do that especially if the new guy has some valid concerns. You probably can't support a total re-write (many people who come in new think we should start over and do it better), but you can create a refactoring plan to fix the worst of the problems if there are any that he brings up.
If you have some time where he is not expected to be fully contributing (and fully accounting for his time by client), it might also be a time when he can start on some of those refactoring things that you have wanted to do but haven't had time to do. Sometimes, it is a good thing to use the new person training period to address some things that aren't in the project plan. They can learn the code base and if what they want to do doesn't work, you haven't affected the existing schedules because you hadn't factored them into the existing schedule yet. And if it does work, you might have a big win making future maintenance easier or security better or whatever the problem is.