How to handle training for a coworker who may not have enough skill?

Question

I was recently promoted to a developer role after having been in a technician role for a few years. In the past year before my promotion, I managed several Access databases that I'm passing responsibility for to another coworker of mine, who is currently a technician, as I'll be focused on other projects. I'll call him John. Our pool of internal candidates who volunteered for this additional responsibility wasn't ideal (none have done any kind of programming since their first half of college, if at all, so John was picked mostly for having the most perceived enthusiasm). I did want to implement one or two "FizzBuzz" styled questions but was told not to by the managers who handled the interviews, as they felt we'd be scaring people off and wanted to come out of the interviews with someone I'd definitely train up and mentor.

It's been about a month since, and I'm having doubts about John's ability to work independently. We did a two week training period that was largely conceptual with some hands-on work thrown in. I've also had him shadow me when I get clarification on requests. I've recently started having him tackle requests and problems on his own. Generally, this ends up in him spending an hour working on his own, having nothing written or worked on, him approaching me for help, then me setting up a meeting with him, unsuccessfully try to egg him into logical thinking of which I end up doing 95% of, problem gets solved, and I'm on my way.

Asking for simple things like "declare a string variable and give it the value from the textbox we created" or "write out an if-else structure that checks whether field x is some value. I'm not looking for logic inside the if-else statement right now, just the if-else block so we can see what steps we should take if field x is not a value we want." generally results in me having to type these out for him, even though we've gone over these multiple times. The few times he's pushed changes through without checking with me (which he's not supposed to do) have resulted in bugs that did affect output in a significant manner and required me making time to correct these.

At this point, we're more or less stuck on grooming him up for this role and I can't really backtrack on his manager's decision. Is there anything I can do in changing my approach to training him in a more effective manner? I'm thinking something related to how he approaches me for help (eg. have some code written first so I can review and offer advice to improve that) would be the best way to go about this, but I'm a bit pressured by his manager to hold his hand for him, so he's not 'wasting' 3 hours not making progress, as he still has technician duties to do. Part of me also says that there's only so much I can do to teach what I consider good programming habits, and at some point, I need to let him sink or swim and not worry about it so I can focus on my primary projects.

Answer 1

Talk to the guy

Do you really want to do this, or shall I pick someone else?

If he wants to continue with this work, ask him what he's having difficulty with and try and work on that. It's possible that he feels that Access is obsolete and learning it is a waste of time for him - you need to work out whether he has a technical debt or one of philosophy.

If he's having problems with the technical side of programming in VB forms, then point him toward some online tutorials and ask him to work through them.

If he feels that Access isn't good enough for him, or that he doesn't feel suited to coding, then simply drop him and choose someone else from the previous candidate pool.

Answer 2

One of my roles at work is training new apprentice developers in a certain programming language. These new trainees come in right after school and mostly with no programming knowledge and limited technical understanding (read: play Counterstrike, watch YouTube).

What I typically do to get them started having basic programming exposure with a beginner friendly book. I explain to them the origins of our technology (we use Perl), why we use it, and how to basically use the operating system (if they are unfamiliar with Linux) to get programs started and such. I also show them the IDE we use (unless they prefer vim or similar), and get them started on the book. I explain that they should work through it one chapter a day, including the tasks, and then I review the tasks with them.

I use a book because time-wise it would not be feasible to teach someone programming logic, syntax of a language and the in-betweens all by yourself. It's way too expensive, and there are already good materials like books and online tutorials.

At the same time, I give them real tasks. In your case, that could be getting reports out of the Access databases, create backups, or write documentation. Having something easy, achievable to do that the beginning is crucial to get the motivation up. You want the guy to be intrinsically motivated. He should enjoy what he's doing.

I typically do this so it's half a day of dull but necessary reading, and half a day of productive task, so they can stay focused on one thing, but do not get bored.

He seems to come and ask for help already, which is good. Also let him know that this is ok. Tell him if he has questions, he knows where to find you. Encourage questions. But if he comes without having done anything, don't do everything for him. Point him to documentation. Give him hints, not solutions. You want to encourage independent thinking.

I also often go and check on the trainees when I walk out of the office to get coffee or similar. I'd just stop at their desk, look over their shoulder for a moment, maybe read some code. Sometimes I ask "are you done yet?" and then "why not?". A bit of a healthy challenge can work to lighten the mood if they are the right type, and it's clearly meant as a joke. You need to acknowledge that it's hard for them, but at the same time take it lightly enough that you don't appear like an unapproachable master (think Mr Miyagi, not Kill Bill's Pai Mei). If they ask a question about how to proceed at that point, give a vague answer. "Have you looked at X yet?" or "Maybe I would check Y", smile and walk away. When you get back, check again if they took the bait. If not, ask them why they didn't check. After one or two of those they usually pick up that it's a queue to help them.

In the past this strategy worked quite well for me, but then my trainees mostly have very little workplace experience and are in their early 20s or younger, so normal office dynamics do not really apply. You might need to tread with more care if your guy is an established worker. In my experience, this especially doesn't work if the trainee is older than I am.