It's a big code base he's coming into, relative to the code he's been working on. Most of his background is 100 line scripts written to be used in isolation and mostly by himself. The test code base he's going into is about 250,000 lines, is object oriented, and is highly interdependent. It's a brand new environment.
So the first change I asked him to make in there was related to a report it spits out. This change is going to involve a lot of things he already knows how to do - string and file manipulation, searching, etc.
When I give someone a project that involves a lot of new learning, I try to make sure it has three attributes:
- It's useful.
- It's straightforward.
- It relies on techniques he's already comfortable with.
We're trying to set this engineer up to succeed, and a comfortable engineer is much more likely to succeed. So we give him a project that helps him stretch his skills but that leaves him grounded in skills he feels comfortable with. The goal here is to introduce uncertainty only in the areas where there is active learning. Everything else - the requirements of the project, whether anyone will care, and language or other techniques - should be easy or familiar. This helps the engineer learn without increasing the frustration level too much.
Learning something large isn't easy. So ease into it - start from what you know, and change only what you need to learn. There you'll find a useful project and a good learning experience. Repeat that enough, and you'll discover a whole new world of skills.