I know everyone learns differently and at different speeds, but there must be an art of finding how to teach a particular student a particular task.

Unfortunately I'm not sure if anyone can teach that art, any more than they can teach the art of creating programs from post-it notes. It's something you learn by doing a lot (teaching or translating post-its), preferably by simple lessons, positive re-inforcement and not giving up. (Okay, you can give up on some :) This sort of training is much more like piano lessons than class lectures. It depends as much on your perceptiveness of the student as your talent as a programmer; perhaps more so, since good teaching leads the student into self-development.

Go with your first suggestion, of giving the student small tasks that will result in callable code. That will help your project and emphasize good practices in the student -- compartmentalizing both the learning and the tasks. It is much easier to explain what is good and bad in a 15 line routine than in a 200 line script.

Based on that experience, you'll see some lights coming on as the student applies lessons to things he already knows. (If no lights come on after a large number of lessons, proceed with the giving up.) That will clue you in on how to continue.

Part of my previous job was to "modernize" a bunch of FORTRAN programmers into C and Perl. I made varying progress with each of them, because each was different and responded to help and lessons in their own ways. That experience emphasized to me what I'd found on my own, that there is quite a lot to learn in learning Perl, but the student can write useful code while climbing the learning curve if the lessons were short and built on things the student knew how to do.