Tools and methodology

What is needed to collaborate successfully and to be productive?

• Identify parts/components of your project: Distinguishing clearly between different parts (database, data access layer, web site, service, API, test projects, build scripts, ...) and environments (dev, staging, production), and naming them consistently has an impact on your oral and written communication (documentation, project names, ...)
• Use a source code management system (just in case you don't yet). Think about how to use branching with your project and setup.
• Automate your builds - make it as easy as possible to set up an environment from your source repository.
• Test projects are a must on big projects, at least for the more complex projects.
• Use staging environment(s) where your project is ready to be used. Also, create and maintain sample data for an automated staging setup.
• Use a bug tracking system which can help prioritizing and planning the development, and also serves as a memory for past bugs and how they were resolved.
• Document each part of your project, some more than others. I personally like: Overview - Architecture - Dependencies - Configuration - Common problems (from here). Sometimes less is more - in order to not let your documentation get outdated, it's better to be concise and let documentation become a part of your everyday activity.

Management / teamwork

... or anything else on the interpersonal level

• Define your expectations of the other developer. Be reasonable, nobody's likely to bring in the same involvement and passion as you do - at least not right from the start. Communicate what you expect and what not, define your and the other one's responsibilities. Not everybody is an engineer, architect, developer, dba and sysadmin, but if that's what you're looking for, choose the right person or you will be disappointed.
• At first, define tasks precisely, and review and discuss the results. Gradually, start less and less micro-managing. The idea is to build up trust and to increase responsibility.
• Plan your project, set goals for your project and for your team for the next year. Write it down and check it later, this will give perspective. Those goals may or may not be communicated to others (as long as they are goals you need to achieve, not others), it can simply be your own checklist.
• Take a day to prepare and plan the first month (or two/three months) of your new developer. I find it extremely motivating when working with well prepared people. Nobody should get the impression that his/her time is wasted.
• Let go. It's your baby, it should become somebody else's, too. Allow the other one to become an expert better than you, at least in some parts of the project. This means actually you succeeded.
• Listen - if you hired her, she's got something to say. Be ready to learn.
• Be ready to share your knowledge and experience (and therefore time - be patient).
• Mistakes will be made, it's how they're handled and what everybody's learning about them what counts.
• Allow time to learn and experiment

Book references

I'll list some of the commonly mentioned books that I've actually read and I think are worth reading, for a more detailed description or for more books you may want to check out some of the questions on SO asking exactly for that, like this or this question.

Those books really are worth reading in respect to teams, organizations, and programming projects:

• Peopleware
• Mythical Man Month
• Software Estimation, Demystifying the Black Art

None of those are practical guides of how to implement methodology X (except Software estimation, this books helps you choose an appropriate estimation process). Of course, books more focused on programming itself like Code Complete are also very enriching.