Get them to do your job for a while.

For example, if your job as application developer is to develop an application, then assign to them your next application development task[s].

Tell them that:

• You want them to do the work
• You're available to answer their questions
• You expect them to take it on themselves to ask you questions

You don't know what they don't know (that you need to tell them) so, instead of your guessing what to tell them, it's more effective if they tell you want they don't know and want to know (by asking questions).

Given that you're able to do the job, you're presumably able (if asked) to explain any specific aspect of it in any amount of detail.

Expect this (training) to take some time. Hopefully, management expect that and are OK with that. When I helped (trained) new hires in this way, I approximated that it would take me as long to explain a task in detail as it would have to actually complete it myself; it took even longer than for the new hire. For example, a job (e.g. a new feature) that might take me three days to do by myself would take me three days to explain in detail, and take the trainee a couple weeks.

The payoff (profit, or time saved), therefore, isn't immediate: the payoff is months later, when the new hire is up to speed and is able to work more-or-less independently.

Oh yes, apart from getting them to ask ad hoc questions, you should do code reviews/inspections of everything they finish. When they say they're ready for a code review, your first question might be "Have you tested this?" In your code review you look for obvious bugs. The ideal clarity to aim for is that code is complete not when "it has no obvious bugs" but when "it obviously has no bugs".

Your code review criticisms should be either:

• Must fix immediately, before check-in (e.g. a bug, doesn't meet requirements, or unmaintainable)
• Optional (e.g. "I see what you've done, and it's not a bug, but FYI I would have done it this way")

Get them to do your job for a while.

For example, if your job as application developer is to develop an application, then assign to them your next application development task[s].

Tell them that:

• You want them to do the work
• You're available to answer their questions
• You expect them to take it on themselves to ask you questions

Because:

• You don't know what they don't know (that you need to tell them); so, instead of your guessing what to tell them, it's more effective if they tell you what they don't know and want to know (by asking questions).
• It requires of them to want to do the work, and to engage themselves with figuring out how.
• It ensure all training is relevant to the task at hand: that it's necessary and sufficient.

Given that you're able to do the job, you're presumably able (if asked) to explain any specific aspect of it in any amount of detail.

Expect this (training) to take some time. Hopefully, management expect that and are OK with that. When I helped (trained) new hires in this way, I approximated that it would take me as long to explain a task in detail as it would have to actually complete it myself; it took even longer than for the new hire. For example, a job (e.g. a new feature) that might take me three days to do by myself would take me three days to explain in detail, and take the trainee a couple weeks.

The payoff (profit, or time saved), therefore, isn't immediate: the payoff is months later, when the new hire is up to speed and is able to work more-or-less independently.

Oh yes, apart from getting them to ask ad hoc questions, you should do code reviews/inspections of everything they finish. When they say they're ready for a code review, your first question might be "Have you tested this?" In your code review you look for obvious bugs. The ideal clarity to aim for is that code is complete not when "it has no obvious bugs" but when "it obviously has no bugs".

Your code review criticisms should be either:

• Must fix immediately, before check-in (e.g. a bug, doesn't meet requirements, or unmaintainable)
• Optional (e.g. "I see what you've done, and it's not a bug, but FYI I would have done it this way")