This page is closely related to StopCoding, and expands on one of it's major points: describing WHAT, not HOW.
A common mistake that beginners make when trying to describe the solution to a problem is to leap immediately to describing HOW they are going to achieve their goal.
This is usually because they are just dying to write some Java code, and their brain is already leaping ahead to what that code is going to look like.
Tip from an old programming soldier: it's a BAD HABIT.
Suppose you had to design a kitchen - Would you start out by describing the pipes and the wiring? NO. Chances are, you'd start out by describing what you want that kitchen to look like, and maybe the sorts of things you're likely to want to cook in it.
Is it a professional kitchen? If so, there may be a few extra requirements like a high-capacity dishwasher or fridge and extra electrical or plumbing capacity; not to mention compliance with Health and Safety regs.
How many people is it likely to have in it when in use? That's likely to have a large bearing on how big it needs to be, and also how appliances and working surfaces are layed out.
Note that all this thought process is required before you lay your first section of pipe or bang in your first nail - and it's all concerned with what the kitchen needs to do, not how it's going to do it. You wouldn't expect an architect to start constructing straight away, so why would you think you can just start coding to solve a problem?
As a programmer, YOU ARE THE ARCHITECT, and the amount of thought you put into a solution is directly proportional to how good it will be. The minute you start coding, you are simply a carpenter, or a joiner; and a carpenter cannot solve design problems.
So, getting back to 'What, not How'...
"When it is not necessary to make a decision, it is necessary NOT to make a decision"
The above is a quote from Lucius Cary, 1st Viscount Falkland, made in 1643; and was at the top of the first chapter of the very first book I ever read about Object-Oriented programming.
What it means is that you should put off irreversible decisions for as long as possible. In his case, he was talking about cutting off the King's head; in programming (or design) terms it means not casting anything in stone until you absolutely have to.
Java is an Object-Oriented language, and objects are all about what, not how. Indeed, the language is full of constructs (in particular, interfaces and abstract methods) that allow us, as programmers, to put off implementation (the 'how') until we absolutely need it. Why? Because 90% - and probably more - of the time, it doesn't matter. And for the rare occasions that it does, you can always include it in your description.
Another point to note is that a good description can be the basis for your documentation; and good programmers are also good documenters.
So, a few simple tips for you:
1. When describing a solution, concentrate on what needs to be done, not how you're going to do it. And when you do actually get around to coding: don't code in a way that relies on a specific way of doing something. It's a recipe for disaster.
2. Don't include Java class names in your descriptions. If you find them creeping in, STOP; and re-think what you're describing. Obviously, certain terms like "list" or "integer" may suggest a Java class, but don't make the mistake of thinking of them in Java terms until you're actually ready to code.
3. If the problem involves displaying something (as many do), separate the display logic from 'what is being displayed' completely. In many cases, you can actually leave out the display part altogether until you know that your problem logic is working.
4. (and this is the trickiest one) Don't be "woolly". Just because you're describing what, not how, doesn't mean that you can afford to leave out essential facts. If something needs to be sorted, it needs to be sorted; and you must include that fact.
You may even need to describe it a little further - for example, that customers need to be sorted by their name - but what you DON'T need to do is describe how you're going to sort them (eg: shell sort, selection sort, quicksort). These kinds of decisions are almost always interchangeable, and you may very well discover that your first inclination was wrong; so don't write descriptions - or indeed code - that rely on them.
At the same time, you also need to be careful not to over-elaborate. As Antoine de Saint-Exupery said: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away". Now, nobody is expecting you to become an 'Antoine' overnight, but it's a good maxim to live by.
Deciding how you're going to do something before you've worked out what you need to do is putting the cart before the horse, and tends to lead to a lot of preventable problems, such as 'coding yourself into a corner'. To paraphrase a colleague of mine: "You don't go to a construction site saying 'I'm going to use a saw', because what you may need is a hammer. You should not let technology (or method) drive your design, but make your design drive the technology".
Amen to that.