I am in a situation where I am to act as a tutor to a new developer on my current project.
What would be the best way for you to quickly get into the project - both technically, domain specific items and socially.
I have read quite a few pro-TDD people talking about pair programming, starting out with the experienced team member writing the tests and the new guy implementing the actual code - then later switching.
What would work best for you?
Are there any in-house tools that have been created using the same platform as the main project? If so a good introduction to the platform would be to get the new person to do some improvements to the tools that you have wanted for a while.
When I get on an existing project I find it easier to get into it if:
Someone shows me the application working, explaining what it is supposed to do, what is done, and answer my initial questions.
I get good documentation so I can find out the basics of the project on my own.
I have someone available to answer any of my questions as they come along.
Get the newbie to fix bugs in your code.
It's a win-win. You can leave them in the corner to work at their own pace. They have an objective. You can set a task in 5 minutes.
I like to do the following:
Once they're familiar with that area, you expand it out, and start giving them small features etc.
The main point of all of this is for them to familiarize themselves with the product, and environment.
Beer!
From the social perspective I always like the whole team to go out for some beers when anyone new comes on. Or if you're not a beer guy, then bowling or Rock Band or something.
They will feel much more comfortable asking questions and fitting in after you're all a bit more relaxed.
There's a combination of techniques:
Firstly, they need to understand what the application does. Sounds trite I know but I've worked in trading applications and it can take people a long time to get their head around what, say, a market maker does because that's built on top of a lot of knowledge about how financial markets operate and what they do. Just a term like "spread" has all sorts of assumed knowledge built into it.
This should be done interactively rather than handing someone a tutorial or a user manual. Also, and this is really important, the user user should drive. Using the mouse and keyboard rather than watching is what builds muscle memory and ingrained responses. You'll get much better retention rates that way. Also, rather than saying "click here now do this" put them on the spot and ask them "what would you do here".
You can often get a useful insight into the usability of your application this way since the new person isn't tainted by all the history that you and your existing team has.
You can't teach someone everything but show them enough that they can navigate around the application and do simple tasks.
Secondly, give them an architectural overview. If this takes more than an hour or two you're going into too much detail. They'll simply forget it. I find it's better to actually give this as a face to face talk rather than handing them an architectural design document (which generally just causes people eyes to glaze over).
Lastly, give them small, relatively easy bugs to fix that aren't time critical. This will get them familiar with the basics of checking out the code, building it, deploying it, running it, etc. It's important that it's simple because things always go wrong with new code. You might need the right environment variable set up to properly build the code or whatever. Give them a complex problem and if something goes wrong they'll get lost in figuring out if its environment, if it's because they're doing something wrong and so on.
It also goes without saying that you can't leave them in a corner to figure this out. Someone eneds to keep an eye on them to make sure they don't get bogged down. This will also give you a good insight into their personality: what happens when they get stuck? Do they freeze up? Do they ask for help? Do they try and nut it out? Do they give up too easily?
At the same time they're learning about the code.
The natural inclination is to start wide and drill down, which results in a lot of longish introductory talks. The new person is barely going to remember any of it. Don't waste your time on the history of the project, the high-level architecture, etc, etc.
Pair them up with an experienced person to work on a single problem. Provide just-in-time explanations of the context of what is being worked on. As you do so, teach them to fish by showing them where to find historical/contextual information. People learn best when they build their understanding from a kernel. People do not retain much up-front "scaffolding" information.
I just start a new job in December, so this process is still fresh in my mind :).
Here are the questions I ran into:
What does this thing do?
How do I do my work?
How do I build it?
What is all of this stuff?
Once all of these questions are answered, I'm ready for work to begin!
The best way to get up to speed on a new code base is to work on well defined, isolated tasks that are structured in a way that I get gradually exposed to more and more components. Also, it's crucial to have people available to answer my questions at all times in case I get stuck or need more information.
My experience here has been great so far, here's the order of things I've worked on: