Regardless of programming language(s) or operating system(s) used or the environment they develop for, what should every programmer know?
I'm interested in becoming the best programmer I can. As part of this process I'm trying to understand what I don't know and would benefit me a lot if I did. While there are loads of lists around along the lines of "n things every [insert programming language] developer should know", I have yet to find anything similar which isn't limited to a specific language.
I also expect this information to be of interest and benefit to others.
Every programmer should know how to accompany code with good documentation.
I find that code that is well documented (liberal use of embedded comments) is easier to maintain and upgrade.
When a programmer embeds their rationale for an implementation (inline to the code), I can spend less time on figuring it out and more time on the task at hand whether it is adding features or debugging other related issues.
Besides knowing how to do the cool, the boiler plate, the borning, and the redundant. Know and learn one thing, you are replacable. Once you get over that, you'll job will be easier. Know that even though there is "internet time", somethings which are worth doing also take time, and cannot be accomplished in five minutes, no matter what your boss thinks.
Figure things out on your own. Or, at least, make a real, honest attempt to do figure the problem out on your own. You'll learn more than you ever will getting the answer from someone else, and it'll be a lot more rewarding.
Attach importance to and know well the Science and Logic of programming more than the technology that you are working on!
Empathise with the end user and do not give him something just to show that you are proficient in some technique or technology. i.e. do not force a rocket to him when what he needs is actually a bicycle.
How to deal with frustrating people without losing your temper.
When the manager drops a list of items on your desk and says he expects them to be done by friday; When the DBA runs a data load script twice; When the sysadmin deploys the wrong version of your code; When the user asks you to explain how it works, again -- That's when you need the be able to handle it with grace. Because you're going to have to work with all these people, and it will go much better if they don't think you're a nasty jerk, no matter how wrong they are.
You will never know as much as you
think you do. Even after a few years in the business, you will
continue to encounter people who know
more than you do about your personal
area of expertise. Don't worry about
it and keep studying and learning.
You will never have learned enough languages or architectures or paradigms or buzzwords. Because
once you think you know it all,
someone will invent a new (insert
favorite technology here) and you
will be out of touch again.
You will be that old fuddy duddy soon
enough. Cut him/her some slack and assume that once upon a time, he/she was in your shoes.
The real world may not run the same as things did when you were in school. Accept that how a company runs its software development isn't going to match exactly what the theory was that you were taught.
Take some time to understand how things run in a new organization. This applies to everyone but grads may hopefully find it more sobering than others.
The skills needed to get a development job and the skills needed to be successful at a development job are often typically two very different things. In making career choices, prefer places where they are the same.
Conversely, in most jobs 95% of your data structure / algorithm needs are served by library classes. 95% of your time will be wasted by dealing with unmaintainable code written by people who are ninjas at CS but have the engineering skills of a lobotomized beaver.