I have had various team lead and senior developer positions that have involved mentoring other developers. I think the most difficult part of mentoring is when a new developer joins an existing project. There will undoubtedly be a lot of knowledge that has been built up over the course of the project that, no matter how good your processes are, will be in exisiting team members heads rather than on a wiki or some other shared document somewhere. My approach in the past (which is true of most people's I believe) is to spend a few hours going over the project structure pointing out key features of the framework or libraries etc and then letting the new dev start developing, making ones self available to answer any questions as he comes up with them. You can try to get the new developer started by looking at bug fixing rather than a new development task in an attempt to flatten out the learning curve, but ultimately I think the approach is flawed. Personally, I am happy to go off and dig around code and work things out for myself. I have found a lot of developers get intimidated by that though. I don't think that is necessarily a true reflection of whether they are a good developer or not. I think it is just some peoples personality, that when faced with a daunting task (which this can be to many) that they panic, shutdown and end up spinning their wheels not really getting to grips with the project or code base etc, let alone any new concepts they are being introduced to for the first time.

Recently I was listening to Java Pose episode #359 - "Roundup '11 - Developer Practices" and I had an epitomy! Of course there is a better way of mentoring/bringing new developers on to a project. The solution in my opinion is pair programming. Well not exactly pair programming in the agile/xp sense as it is meant to be peers that program in pairs, but sitting down in front of a computer, maybe letting the newbie drive and working through a development task (or tasks) together. I think that only by taking this approach can you effectively start to pass on the knowledge a new team member really needs to get up to speed on the project quickly. As you work through a problem together you will come across things that you need to mention that you would never have covered in a 2/3 hour overview. Similarly the newbie will get to see how you approach the problem as well as your thought processes and how a certain problem should be approached within the boundaries of the current project. You will be able to get immediate feedback of what the new guy is finding difficult and what they aren't and since you're sat next to them they won't end up spending days trying to figure out trivial problems.

How long this pair programming should last is dependent upon the level of the new developer as well as the complexity of the problem. Maybe a few hours will still be enough for an experienced lead developer to get up to speed, but I don't think it is a problem if you are still doing it after a week. A junior developer is likely to require more time and if that is the case then maybe multiple members of the team can take time to pair with them. I think it is fair to say that if the new guy still requires this level of support after his three month probationary period then it's probably time for them to go