It sounds like you and your co-worker (as well as your manager) need to agree on the level of quality the both of you want to produce as a team, and figure out a process to get there, one that doesn't have your co-worker constantly leaning on you for support.
For instance, you and your co-worker need to come to an agreement about what should be expected out of a task before calling it "done" and moving on to the next task, and you shouldn't move on to the next task until your assigned task is done. This definition of done should include having tested the code to ensure that it meets all requirements and doesn't break any existing functionality. It should also include some level of code review and a code quality check just to make sure that you and your co-worker can agree as a team that the code is worth publishing.
You might think of a few more things to add to that definition, but the important thing is that if something isn't considered done by your agreement, it needs to be sent back and completed before taking on another development task. Over time, this will send the signal to your co-worker about what he/she is expected to produce in terms of code quality, and hopefully he or she will match those expectations over time. (If your coworker's code quality still doesn't improve, it might then be time to talk the situation over with your manager.)
Lastly, if you do find that your co-worker is too dependent on you for things that need to get done, you should probably point him to a few sites (i.e. stack overflow) to find answers to his questions, and tell him that you don't have time to constantly help him out.
Furthermore, from a project management perspective, experience breeds speed; you should expect that it will take your co-worker longer to complete tasks than it will take you. As a result, you should not set your deadlines with the expectation that your co-worker will be able to match your development speed.