Part of what you will learn from this exercise is ensuring you have a good, clearly communicated design with your team mate.

Working alone you could “wing it” to some extent, by coming up with some “design” but then changing it at will, since it will only affect your own work.

Working in a team (2 or more people) means you should both work together to properly design what you are writing, and ensure that your “interfaces” or contracts are properly defined. I put “interfaces” in quotes, since they may not be proper OO interfaces, depending on the language you are using.
(In school, it’s a good idea to work together on the design, whereas in the real world it will often be one person doing the design, and assigning modules out to the team)

Once you have this properly thought out design, each person in the team can then develop a part of the whole system (a class, or a discrete area of functionality), and as long as they program to the agreed interface/contract the modules of the application should slot together.

One approach you may wish to use is the Feature-Driven Development approach, which means that 1 developer is responsible for an entire feature of the whole application, and as long as it fitted into the application “core” which glued the whole application together, they were more or less free to develop it as they saw fit. (this also makes it easier for lecturers to mark it, since they can clearly see which student wrote which piece)

NB While I am a big fan of pair programming, and use it regularly in my day-to-day job, I’m not sure if I agree that it would be of benefit in this situation, since it’s too easy for 1 developer to just “tune-out” of the development. This is something which I usually only recommend for a complex piece of code, that can benefit from several pairs of eyes to get right.

Since it’s school/university you’ll probably better off doing pair programming. You’ll be able to both correct and learn from each other.

http://www.jamesshore.com/Agile-Book/pair_programming.html

Jean-Paul Sartre in his play No Exit, famously said, “Hell is other people.” Of course, for everyone on this planet, except you, you are other people, so there is a lot to work on.

Team projects in school and in the work place can be filled with challenges. There are some helpful tools you can use:

• Start early.
• Create some goals for yourself about what you would like to learn and do on the project.
• Spend more time that you expect selecting partners.
• Keep your team small.
• Understand your differences.
• Seek out people with complementary strengths, contrasting ideas, diverse backgrounds.
• Understand and manage group dynamics.
• Understand communication and thinking styles (external – talk it through, internal – plan it out, write it down).
• Pick someone who is equally serious about the class or project as you.
• Work with people who have a compatible schedule.
• Create a shared understanding of what the professor (or manager or scrum master) expects.
• Communicate frequently.
• Try to make things an equal partnership.
• Don’t quibble about who is working or accomplishing more.
• Be attentive and accommodating.
• Show appreciation early and often.
• Be happy and positive about working together even if problems arise.
• Expect to have tough days, so use easy days to build working relationships.
• Bite your tongue if you are tempted to say things like “I hate you, I would never work with you again” because after that happens, everything will get harder and you won’t have the career long friend that you should make in college. Our business is not so large we won’t make or accept job applications to/from that person later, particularly since the advent of Linked In.
• If your partner is stuck, provide help.
• If you are stuck, ask for help.
• Use collaboration tools.
• Be as aware as possible of the work others are doing. Your interest is motivating to the other person.
• Peer review each others work. Recommend, but steer clear of criticism that is personal, permanent, or pervasive (“you always screw up everything” is not helpful).
• Understand what constitutes plagiarism and take steps to insure that your work and the work of other members of your team is original and properly attributes the work of others.
• Enjoy the work.
• Understand what worked and what didn’t.
• Share the credit for the success, but don’t recriminate if things didn’t meet expectations.

Is the goal to divide the work up and decides who does what or should one person code and the other person reviews and switch roles after a while?

Unless your instructor explicitly told you how to share the task, it is up to you and your partner to decide. So I would start by discussing this with him/her. This includes a rough assessment of your qualities and skills – nothing bad, just to see whether you are more or less on the same level, or one of you is more skilled / experienced in some aspect of the work. This quite strongly influences your options.

If the two of you are on about the same level, probably the best is to attempt to solve at least the most fundamental tasks – fleshing out a rough design and implementing a skeleton application in code – together.* You don’t need to make a shiny perfect design up front – it takes a lot of experience to succeed with this. It is better to just try to come up with ideas, discuss how the program could work the way it is expected, and if in doubt, write code to verify your ideas. The outcome of this is a skeleton, containing all the main parts of the program and capable of some very simple functionality to demonstrate that the system is working end to end. E.g. the skeleton of a word processor would be able to open a very simple file, display it in an editor window, then save it. A skeleton web server would be able to respond to the most basic HTTP GET request by sending back a “200 OK” response with some hard-coded content. Etc etc.

Once you are ready with this, you may start dividing up tasks between the two of you if you prefer so. In fact, the second main aim of creating the skeleton is to allow multiple people to work on the code in parallel. Which implies that putting everything into a single source code file is not the best idea here 😉

One (possibly obvious) note: if you haven’t used a version control system before, now is the time to start using one.

If, OTOH, one of you is noticeably more skilled / interested in some area, it may be obvious to give related task to him/her. The other may want to watch and follow though, or to get a presentation afterwards, to learn that skill too. At a later point in time, when both of you already are familiar with the basics of teamwork and solving problems, you may choose to do the opposite, letting the lesser skilled one to do a specific task in order to even out your skillset.

*Side note: This process may or may not include pair programming. If both of you are open to the idea of pair programming, why not give it a try. However, make sure that you are really working together, with both of you participating and switching roles frequently. If one of you is dominating and the other is just trying to stay awake, this does not help either of you, and just gives a bad experience.

So if you don’t like the idea of pair programming, and/or you have some bad experience (as you seem to have mentioned in your post), and/or you feel it would be one thing too much to learn at this point, you may leave it off. Still you need lots of cooperation between the two of you, so make sure you meet, discuss and share your results with each other frequently.