Gather complete requirements.

Take the time to write down what the end product needs to achieve. Clarity of thought at this stage will save a lot of time down the line.

Write an implementation plan (or model).

For something small and self-contained, this might just be a basic flowchart or an equation.
For larger projects, it helps to break it into modules and consider what job each module must do, how data gets passed between modules, and within each module how it will function.
Although it is fun to dive straight into code, it is equally tedious to spend hours debugging. By taking the time to design the structure on paper, you will drastically reduce your debugging time (and you may also spot more efficient ways of doing things even before you write the first line of code).

Add Comments to your code.

Whenever you feel your code needs some explanation, drop some comments in. Each function should be preceded by 1-2 lines describing the arguments and what it returns. (Comments should tell you why more often than what. Remember to update the comments when you update your code!)

Use naming conventions for variables.

It will help you keep track of what type the variable is and also what it's purpose is. Although this means more typing than x = a + b * c, it will make your code easier to debug and maintain. One popular convention is Hungarian notation where the variable name is prefixed with its type. e.g. for integer variables, intRowCounter; strings: strUserName. It doesn't matter what your naming convention is, but be sure that it is consistent and that your variable names are descriptive.
(See Warnings below)

Organize your code.

Use visual structure to indicate code struture. i.e. indent a code block that sits within a conditional (if,else,...) or a loop (for,while,...) Also try putting spaces between a variable name and an operator such as addition, subtraction, multiplication, division, and even the equal sign (myVariable = 2 + 2). As well as making the code more visually elegant, it makes it much easier to see the program flow at a glance.
(See tips on indentation below)

Test.

Start by testing it with inputs that you would typically expect. Then try inputs that are possible but less common. This will flush out any hidden bugs. There is an art to testing and you will gradually build up your skills with practice.
Write your tests to always include the following:

Extremes: zero and max for positive values, empty string, null for every parameter.
Meaningless values, Jibberish. Even if you don't think someone with half a brain might input that, test your software against it.
Wrong values. Zero in a parameter that will be used in a division, negative when positive is expected or a square root will be calculated. Something that is not a number when the input type is a string, and it will be parsed for numeric value.

Practice. Practice. Practice.
Be prepared for change.

In a realistic working environment, requirements change. However, the clearer you are at the start about the requirements and the clearer your implementation plan, the less likely those changes will be down to misunderstanding or "Ah, I hadn't thought of that" scenarios.

You can take an active role in improving clarity of thinking by presenting your requirements document or your implementation plans before coding to ensure that what you are planning to create is actually what's been asked for.
Structure the project as a series of milestones with a demo for each block. Approach the programming one milestone at a time - the less you need to think about at any moment, the more likely you will think clearly.

Start simple and work towards complexity.

When programming something complex, it helps to get the simpler building blocks in place and working properly first.
For example, let's say you want to create an evolving shape on screen that follows the mouse and where the degree of shape change depends on mouse speed.

Start by displaying a square and get it to follow the mouse, i.e. solve movement tracking on its own.

Then make the size of the square relate to mouse speed, i.e. solve speed-to-evolution tracking on its own.

Finally create the actual shapes you want to work with and put the three components together.

This approach naturally lends itself to modular code writing, where each component is in its own self-contained block. This is very useful for code reuse
(e.g. you want to just use the mouse tracking in a new project), and makes for easier debugging and maintenance.

The list

* Ada

Ada is a tank. A butt-ugly tank that never breaks down. People laugh uncontrollably if you tell them you drive Ada, but really, do you want to be driving a sports car in a war zone? [from Amit Dubey]

* Assembly Language
is a bare engine; you have to build the car yourself and manually supply it with gas while it's running, but if you're careful it can go like a bat out of hell.

[From "Subterfug" off digg.com:]

Assembly Language: you are the car.

* Basic

Basic is a simple car useful for short drives to the local shops. Once popular with learner drivers, it has recently been stripped down to a shell and rebuilt by a major manufacturer, The new version has been refurbished for longer journeys, leaving only cosmetic similarities to the original model. [from Przemyslaw Wrzos]

* C

C is a racing car that goes incredibly fast but breaks down every fifty miles.

* Cobol

Cobol is reputed to be a car, but no self-respecting driver will ever admit having driven one.

* C#

C# is a competing model of family station wagons. Once you use this, you're never allowed to use the competitors' products again.

* C++

C++ is a souped-up version of the C racing car with dozens of extra features that only breaks down every 250 miles, but when it does, nobody can figure out what went wrong.

* Eiffel

Eiffel is a car that includes a built-in driving instructor with a French accent. He will help you quickly identify and learn from your mistakes, but don't you dare argue with him or he'll insult you and throw you out of the car. [From Daniel Prager with some embellishments]

* Erlang

Erlang is a fleet of cars that all cooperate to get you where you want to go. It takes practice to be able to drive with one foot in each of several cars, but once you learn how you can drive over terrain that would be very hard to navigate any other way. In addition, because you're using so many cars, it doesn't matter if a few of them break down.

* Forth

Forth is a car you build yourself from a kit. Your car doesn't have to look or behave like anyone else's car. However, a Forth car will only go backwards.

[By "256byteram", on a comment on Digg.com (I couldn't resist):]

FORTH LOVE IF HONK THEN !

* Fortran

Fortran is a pretty primitive car; it'll go very quickly as long as you are only going along roads that are perfectly straight. It is believed that learning to drive a Fortran car makes it impossible to learn to drive any other model.

* Java

Java is a family station wagon. It's easy to drive, it's not too fast, and you can't hurt yourself.

* Haskell

Haskell is an incredibly elegantly-designed and beautiful car, which is rumored to be able to drive over extremely strange terrain. The one time you tried to drive it, it didn't actually drive along the road; instead, it made copies of itself and the road, with each successive copy of the road having the car a little further along. It's supposed to be possible to drive it in a more conventional way, but you don't know enough math to figure out how.
[Monadic version:]

Haskell is not really a car; it's an abstract machine in which you give a detailed description of what the process of driving would be like if you were to do it. You have to put the abstract machine inside another (concrete) machine in order to actually do any driving. You're not supposed to ask how the concrete machine works. There is also a way to take multiple abstract machines and make a single abstract machine, which you can then give to the concrete machine to make multiple trips one after another.

* Lisp

Lisp looks like a car, but with enough tweaking you can turn it into a pretty effective airplane or submarine.

[from Paul Tanimoto:]

Lisp: At first it doesn't seem to be a car at all, but now and then you spot a few people driving it around. After a point you decide to learn more about it and you realize it's actually a car that can make more cars. You tell your friends, but they all laugh and say these cars look way too weird. You still keep one in your garage, hoping one day they will take over the streets.

* Mathematica

Mathematica is a well-designed car that borrowed a lot from the Lisp car without giving it nearly the credit it deserved. It can solve equations to determine the most efficient way to get to the destination, but it costs a fortune

* Matlab

Matlab is a car designed for novice drivers going on short trips over terrain similar to the terrain the Mathematica car is usually driven over. It is very comfortable when driving over this terrain, but if you go off the trail even a little the car becomes so hard to drive that more snobby drivers refuse to even acknowledge that it's a car.

* Ocaml

Ocaml is a very sexy European car. It's not quite as fast as C, but it never breaks down, so you end up going further in less time. However, because it's French, none of the controls are in the usual places.

* Perl

Perl is supposed to be a pretty cool car, but the driver's manual is incomprehensible. Also, even if you can figure out how to drive a Perl car, you won't be able to drive anyone else's.

* PHP

PHP is the Oscar Mayer Wienermobile, it's bizarre and hard to handle but everybody still wants to drive it. [from "CosmicJustice" off of digg.com]

* Prolog is fully automatic: you tell it what your destination looks like, and it does all the driving for you. [Addendum from Paul Graham:] However, the effort required to specify most destinations is equivalent to the effort of driving there.

[I forget who suggested this one:]

Prolog is a car with a unique trial-and-error GPS system. It will go down the road looking for your destination, and if it gets to the end of the street without finding it, it will back up and try the next street over and continue until you get where you need to go.

* Python

Python is a great beginner's car; you can drive it without a license. Unless you want to drive really fast or on really treacherous terrain, you may never need another car.

* Ruby

Ruby is a car that was formed when the Perl, Python and Smalltalk cars were involved in a three-way collision. A Japanese mechanic found the pieces and put together a car which many drivers think is better than the sum of the parts. Other drivers, however, grumble that a lot of the controls of the Ruby car have been duplicated or triplicated, with some of the duplicate controls doing slightly different things in odd circumstances, making the car harder to drive than it ought to be. A redesign is rumored to be in the works.

* Smalltalk

Smalltalk is a small car originally designed for people who were just learning to drive, but it was designed so well that even experienced drivers enjoy riding in it. It doesn't drive very fast, but you can take apart any part of it and change it to make it more like what you wanted it to be. One oddity is that you don't actually drive it; you send it a message asking it to go somewhere and it either does or tells you that it didn't understand what you were asking.

* Visual Basic

Visual Basic is a car that drives you. [from "yivkX360" on digg.com, no doubt channeling Yakov Smirnov