Stop Coding (Wiki forum at Coderanch) (original) (raw)
(Level: Beginner)
When you're starting out with Java, there is a tendency to want to dive straight into code. It's new, it's fun, and when you get it right there is instant reward from seeing the correct result or something neat appear on the screen. Furthermore, while you're in a class or following a book, it often works, because you're being told what to do and learning at a pace you can handle.
But the fact is that starting to code straight away is a BAD HABIT - and one you need to break as fast as you possibly can.
So here are a few simple rules:
1. You will NEVER solve a problem in Java unless you can describe it in English (or your native language).
2. When describing a solution there are two main things to consider:
- WHAT needs to be done.
- HOW you're going to do it.
And, of the two, WHAT is much more important than HOW - especially early on in the process. Unfortunately, most beginners are far more interested in the latter because their minds are already racing ahead to Java code; and code is all about 'HOW'.
So...
3. When you run into problems: STOP CODING.
My advice also usually includes:
- Switch your computer OFF.
- Get out a pencil and paper and write down what (that word again) you're trying to do ... for a second or third or fourth time if necessary. Draw diagrams, think of scenarios - especially ones that might make your program FAIL. Any fool can write a program that works when everything is fine; a good programmer writes ones that handle the situations when they aren't.
- When (and only when) you've finished that last step, turn your computer back on and take another look at your code. Quite often you'll find that it's complete rubbish and you have to start again. And you know what? That's GOOD, because now you're really designing - and with practise it will happen less and less frequently.
4. When you're writing code, don't write more than 10 lines or so without compiling (and some would say even less than that). Even most experienced programmers I know follow this rule, because they know how difficult it can be to untangle a mess of compiler errors.
.
Programming is thinking, not coding; and the sooner you learn to think before you code, the sooner you will stop 'coding yourself into a corner'.
The average professional programmer spends about 20% of his/her working life actually coding (and often less than that); the rest is spent thinking, writing, and documenting what they've done. So if you find yourself spending a lot more time than that in front of your IDE or source editor, chances are you're doing it WRONG.
.
And now, if you haven't already, I suggest you look at the WhatNotHow page.