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.