Well ... This one has all the hallmarks of 'how long is a piece of string?'.
Your use of the word 'inherited' indicates to me that you did not recruit
him yourself. How he came to be working for your company is a major factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a more
'mainstream' area of the company, or perhaps recruited by someone else in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the company. In
addition, is this person 'new' to you personally or have you known him for
some time. This sort of information is important to you so that you can
gauge his ability to learn, his level of self-motivation and perhaps his
abilities in analysing and solving 'problems', which, after all, programming
is all about.
Realisticly, you have to gaugue his skill levels in various areas and the
best way is to start at the beginning. That is to start him off on 'ye olde
standard' Hello World! console application. This should have the intention
of introducing him to the VS IDE, the VB.NET compiler and the VS Debugger.
It important that he understand what is actually happening when the app hits
the 'Sub Main()' because, in Access, the need to worry about that level of
functionality was hidden from the user.
As you are satisfied that he has mastered each step, increase the complexity
of the exercises at the rate you gauge to be appropriate. Some people learn
faster than others and some are able to grasp very complex concepts very
quickly indeed.
Reinforce the need to have Option Explicit and Option Strict turned on in
ALL projects, again making sure that he understands why.
Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make sure
that he is given a copy of the company standards manual as early as
possible.
In parallel with this, introduce him to existing projects. For example, take
a small app and get him to dissect the code to understand what the app is
doing. It is not good enough for him to tell you he understands it, he must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also provides
me with a way of gauging their written communication skill level. Make sure
you review the report with the person, reinforcing where they have 'got it
right' and correcting where they haven't.
Once you can gauge that their proficiency levels are at a certain stage you
can send them out 'to play' on their own, but still reviewing what they are
doing. As their skill levels increase you will be able to reduce the amount
of reviewing that you need to do. When he makes a 'mistake' make sure you
don't browbeat him with it, rather, uUse it as an opportunity for analysis
and learning.
At all steps along the way, you, of course, need to make sure that you are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.
If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.
Unfortunately there is no 'magic bullet' formula that dictates how long such
a process will take just as there is no 'magic bullet' formula that tells
you how you must go about it.
I have a slogan (which is never erased) written in big letters across the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.
Good luck.