Do I just
- write and refine the code as I go?
Yes, this is usually what new programmers do.
- or do I plan the architecture of the code before I even start it, like this class goes here, this method here?
This is what you do after you've tried the preceding method for a while and decided that there must be a better way.
There are a lot of different methodologies because there are a lot of different programmers, and they don't all work best the same way. That said, jumping right into the coding phase is a sure sign of inexperience. Whenever you've got a problem to solve, it pays to develop an understanding of the problem and a plan for solving it first. It's easy and cheap to make big changes to a newly-hatched plan; making big changes once you've written a pile of code is not so easy and not so cheap.
Usually, you start off with some sort of determination of the requirements. This might be a written document that completely details all the required behaviors, or something as simple as a page or even just a paragraph stating the problem, goal, and approach, or it might be something in between. What you choose to do here depends on who you're writing the program for: a contract project for a government agency or a big business will usually need more detailed requirements than a hobby project that you're doing for yourself and your friends.
Once you have an understanding of what you're going to write, you'll develop a plan of attack. Again, that could be a detailed implementation plan with all the interfaces specified, it could be a diagram on a cocktail napkin, or it could be something in the middle.
Setting up a project is another step that you should tackle before you start writing code. Some time spent thinking about the process of how you'll manage the code at the beginning avoids problems later. How will you manage different versions of the code and products, keep track of bugs, make sure you're sticking to the requirements, and communicate/collaborate with others? This doesn't all have to be done at the outset, but it's helpful to at least have a plan.
So, there's a lot that you should at least consider before you really get rolling with your IDE. You don't always need a super-refined process, and too much process can hold you back as easily as too little. Worrying about getting every detail of the architecture perfect before you write a line of code can be as debilitating as being stuck with a pile of poorly considered, difficult to manage code. Just remember that the process -- the planning, tools, documentation, etc -- is supposed to help you build a better product.