You need to find out what his problem really is. Chances are that he is just not motivated.
There is a good theory behind this called "Flow" by work of Csíkszentmihályi:
I am not expert on that but it is very worth to know. Apart from that:
I have some ideas for what his problems may be but before going into details, I provide a TLDR option:
In the meantime I would opt emptying the task queue to a single task, as some of us already advised.
Working in pairs can also be a godsend; he must of course feel involved in it.
Simply tell him what you do if you have troubles to focus. (He will most likely simply understand why you are telling him this.) For example, what I use to retain focus:
- make sure that I spend the first 15 minutes of my day with the real part of my work (ie. do not read coworker emails, etc., but do code). sets the mind.
- close the web-browser. I won't actually need that reference for another 15 minutes, do I?
- if I need I use Tiny Time Tracker to measure how much time do I spend with something
- if I need I use Tomighy as a funny way to make me retain focus on a single thing
- keep pen and paper and have a physical todo list
- cut out everything from the todo that is only "might be useful... someday... for someone... including myself"
- have a plan on who do you want to become and how it is helped by this money you got for your work, or how your work help you with it, if it does
- decide whether it is actually better for you to work for that plan, instead of doing something else, eg. "what am I doing here"
Some ideas about possible problems:
He is just doesn't feel involved enough
The decisions are made without him, he is expected to comply with them, without seeing the reasons, without being able to throw his own reasons into the scales. All the same time not getting or being too afraid to ask help from anyone. I try to unfold this in the next two long ones. :)
He misses information but doesn't have the guts to ask it because he worries about asking something that looks him incompetent. He also may don't realize the actual questions, only feel uncomfortable.
It also needs to be realized that these questions are at least of three kind: technical questions about your workplace's code base, questions about the workplace culture itself (how do you know the requirements, how people exchange information, how people are notified about important changes, events, etc.) and there are technical questions that "everyone could know". He may not realize this what makes him overly separated.
The last item is causing the problems here, since it may make him afraid to ask anything. What I try to do to counter this is asking questions when I feel a certain uneasy in the air; questions that are focused on the most likely culprit of the unease and purposefully tell you it's "ok to be silly". For example, while talking about a piece of code I feel a change in the 'climate' every time when we're discussing something that involves our (hypothetical) in-house magic pointers. I do ask, "did you work with our magic pointers before?" or "I always had troubles understanding these magic pointers when I was new do you find think they are hard?".
The unease may strike at places where he really should have known better, but there is no point letting this get in the way. I may notice he may have problems with (normal) pointers actually. I do ask, "do you use pointers in university?" or "did they teach pointers well in university?" - it may not be his fault after all, but even if it is, you are better off if you try to ease the situation.
Questions like this may uncover problems while trying to set a climate where it is ok to ask. It is very important.
He may have a hard time designing or working with complex code.
When it comes to creating complex code that many other people will use, like a nice API, or deciding on code roles and classes; there is a pressure that you only have one chance to get it right. Right? Universities may do a quite bad job training anyone for this. I asked the best teacher at mine and he told me handling this takes expertise, and some easy things like self-documenting names.
What I feel useful with this is a prototype milestone where everything works but the code is (allowed to be) garbage. This can be applied to stand-alone tools, maybe modules, less so with more internal stuff.
Another very helpful thing may be code review. We use ReviewBoard and a constructive style guideline for commenting. This I find a blessing. But it can be done with less initial effort too eg. shared folders, at desk or in emails. The only problem I find with it that it's hard to review designs or APIs that way.
That's why the third godsend for me is some kind of design meetings for more complex code. (Complex may mean different things for different people but based on his reluctance of actually doing a task and the common level of complexity of those tasks may give you an idea.) This is where mental knowledge of requirements can clash with actual necessities of code that needs to be physically be written. It may help you a lot if you are not alone in this. Of course this must be made to be a collaboration, not a teaching lesson. If the he is not accepted the meeting or is not involved in it than it's useless.
If this is the case you must make him understand that you are trying to help him because you need to reach the priorities as a team, but you fail to see what his problem is.
At a design meeting some example problems that can be dealt with are what roles are need to be represented in code in order to fulfill the proposed requirements. Cutting down everything that is not necessary. Discussing which way to do it, while gathering a list of reasons, best to be written on paper or a table and then photoed, of why should we do it this way why not another way, gathering reasons for them until everyone involved, most importantly him, feels ok with the design.
How each role is best implemented (func, class, module, package, etc.), who is interested in which one, who will do what.
It is very important to see the boundaries of purpose in code, but it can also be very hard if you haven't let yourself fail yet - which could teach you a lot and is better than doing nothing.
Just my two cents (*200 pounds :P) ... hope it helps.