This list is a start… you’re asking a big question!

• How to clarify and write down what the customers wants (“requirements”). This is an art in and of itself. If you can do this, your programming job will be much better.
• How to estimate and project plan. People will ask you for an estimate, be prepared.
• How to constructively review other people’s code.
• Design patterns. This is a big one. But don’t overzealously use them for the sake of it.
• Learn the difference between a bug, issue and feature requests
• Keep up to date with frameworks/libraries. You don’t have to use them, but you need to know what they do and their pro’s/con’s. If something seems way too hard then there’s probably (hopefully) a much easier way of doing things.
• How to document complicated algorithms in a flowchart or just write it out in english. Don’t expect that someone will spend 2 days trying to reverse engineer your code.
• How to organise your code structure so that anyone else can understand it
• How to comment your code
• How to write unit tests
• Know what’s going on under the hood. Eg calling a web service – what’s it actually doing?
• How to abstract away logic into classes.
• How to refactor code
• Learn the gist of quite a few programming languages. You’d be surprised what you can learn from other areas
• How to tell other programmers what to write.
• How to explain to management what you’re doing and why.
• Like Peter said, how to debug. I agree with everything he says, real programmers debug, not just guess.
• How to work with maniacs. There’s a lot of them out there.
• How to GET STUFF DONE. All the theory in the world won’t help you if you can’t get stuff done.

I answered another question along similar lines (with similar content) here:

tips, guidelines, points to remember for rendering professional code?

Under the heading of “etc.” comes something which can easily take 50% or more of your time.

Learn how to debug.

This means learning the Scientific Method. I mean really learning it. And then applying it with brutal self-honesty. Learn how to state precisely what you know is true, what you know is not true, and those things which you don’t know. Any time you sloppily assign an item to the wrong category, you’ve just made your life a lot harder.

Learn to say “I think” instead of “I know”. You only get to say “I know” when you “think” something is true (or false), and then you prove it!

Many bugs are trivial, but they can be hard to see because you “know” what the code should be … except it’s not. Find a freind to explain it to. Ask them to be an “expert idiot”: someone who doesn’t know your code, but who you know you can’t blow BS past. Don
t be surprised if in the middle of a describing it to them you suddenly stop and say, “and so you can … see … see that … sh*t. Thanks.”

Nontrivial bugs require an arsenal of techniques. A classic that can quickly spotlight most non-timing related bugs is Wolf Fence in Alaska. There is a wolf somewhere in Alaska; build a fence cutting the state in half. Which side is the wolf on? Cut that side in half. Lather, rinse, repeat. Doing this 20 times at well-chosen places in the code reduces the area where the bug (wolf) can be to 1/1048576. Kill that wolf.

Tip: look for handwaves—physical, mental, or any other kind. As soon as you (or your colleague) flinch / divert / minimize attention paid to a portion of the code, go totally rabid. Because the area where you just know the bug can’t be, even though you’ve spent hours / days looking for the d*mn thing and still can’t find it … that’s the highest probability location for the bug. Nobody gets a ‘bye’, nobody (including the machine, the OS, the compiler, or you) gets any sort of “due respect”. There’s a bug. Period. End of sentence. Now go kill the d*mn thing.

I know of no school that teaches debugging as a subject unto itself. IMNSHO, this may be the single most glaring piece of evidence that they (universities / professors) are not teaching you to be a programmer, they are, instead, teaching you to be … like them? Harsh? Perhaps. True? Make up your own mind. Now prove it.

I’m afraid this is a pretty large question for anyone to answer conclusively or authoritatively, especially given that you want a prioritized list. There are lots of programmers out there, and they work on very different things – sure, fundamentals stay the same, but what you need to keep active in your memory can be really different, and indeed there are lots of tasks where you can stay pretty high-level without going deeper.

It seems though that you are genuinely concerned about how to be a better developer, and not just a jack-of-one-trade. I find that admirable, and I can share some of the things that have helped me learn how to program.

Pretty much all of programming boils down to algorithms and data structures. They, in turn, are examples of the larger question – how do we model things and processes from the real world into a representation such that a computer can understand. If you are just starting out, it might be useful to use a higher-level programming language (like Java, Python, whatever) to become familiar with implementing data structures and algorithms.

At a certain point, having played around with data structures and algorithms, you may start getting that gnawing question “but how do we go from telling the computer what to do, to the computer actually doing it?” Then you can look into how a computer actually computes – how memory and the CPU work together to execute instructions, how operating systems abstract the hardware so you can write a program that, say, opens a file, without coding to a particular low-level hard-drive interface.

This is probably a good point to start – how algorithms and data structures model problems from the real world, and how a computer actually performs computation. Knowing the latter is very useful in mastering lower-level languages like C, which utilize far fewer smoke and mirrors than OO and scripting languages 🙂

YAGNI: “Always implement things when you actually need them, never when you just foresee that you need them.”

In my experience, it is common for “programmers” to foresee many cases in the future and try to “improve” the code by adding codes to anticipate them! In most cases the code that they added will just bloat the code and add complexity to the code.

The most important thing to know about being a programmer is that writing code is a grind, and a workmanlike “blue collar” attitude towards producing what you’re being paid to produce will get you farther than any esoteric learnings.

Learn to get into the zone. By that I mean the mental state when you’re focused only on your task and you can begin to keep a great many things in your head and how they interoperate all at once. Once you’re in the habit of getting into the zone at will, start worrying about the rest. Until you can pound out code like some kind of a code pounding out thingy, the rest is virtually useless.

EDIT:

If you don’t believe this and you downvoted me I beleive that you do not know if you have the determination to do it for 20 years. I know that I do because I accept this. 😉

A recent question, related in some way to this one, and Answer had a link to This blog which discusses the same problem from a different angle.

Probably the most important concept for any developer is “humility”….Once you accept you don’t know it all, you are open to explore solutions. Most of the people who write blogs on programming are in the top percentile, and the problem is many have yet to control their narcissistic tendencies…. which is why they blog….. You need to learn to identify these bloggers and ignore there rants

The linked blog is really nothing more than a rant – In every industry complains that recent graduates are useless are common, that it takes years to get them useful and productive. Perhaps the problem is that these self proclaimed guru’s actually expect too much and have forgotten that once they would not have been able to solve FizzBuzz. Not everyone can be in the top 10 percentile, by definition, half of programmers are below average……