What should every programmer know?

Humility. You're a human being, not an extension of the machine you're working on. You don't and will never know everything and you will always make mistakes.

Knowing how not to reinvent everything. The vast majority of problems a developer faces has been faced and successfully solved by smarter developers a long time ago. Not using this knowledge is the biggest mistake a developer can make. In the worst case one will not be able to solve the problem. In the best case one will waste time coming up with a solution that already exists.

Goran

If P == NP

And Assembly, on some platform. Probably will never want to use it but an awareness that it's not turtles (or objects) all the way down, the byte stops here.

I am of course joking about NP, but an understanding of what problems are actually difficult to solve problematically can be quite helpful.

Understand the difference between idealism and pragmatism, and why both are important when designing software.

These are things I've learned myself from trial and error over the course of my education and career. I'd say these lessons have served me well although it's sometimes a struggle to overcome my own shortfalls.

1. How to conceptualise a problem before trying to code it. Designing up front is important and having the ability to properly conceptualise the problem helps to get a good design.

2. Humility. We never stop learning and we should never assume we know it all. There's always something to learn, and we're always going to have times when we're wrong. It's important to recognise and accept that.

3. How to break code. Many I have worked with (including me) have coded to meet requirements and didn't spend enough time checking that the code was robust to bad data and bad control flows.

4. How to understand code. Borrowing from others is not a bad thing, but borrowing without understanding what is being borrowed is a bad habit to get into. Just because it looks like a duck and quacks like a duck doesn't mean that it won't eat like a lion, or BM like a flying elephant.

To put themselves in the shoes of the developer potentially taking on the project after them - commenting well and naming sensibly.

Every programmer should at least once see his customer/user. You'll get a better view of the user and why he has sometimes such 'odd' requirements.

If you get a bug report, do not search a person to blame and rethink. Maybe it is your fault.

Recently, I've read credible blogs from technical managers complaining that almost all job applicants for programming positions can't actually code, including those with CS degrees. If this is true, then the answer to your question is clear: what every programmer needs to know is whether they can actually program. Without warning, you should be able to listen to a simple problem, then sit at a computer and code a correct solution in a few minutes.

See http://steve.yegge.googlepages.com/five-essential-phone-screen-questions

General:

• How to learn (things are always going to change)
• How to communicate with non-technical people
• How to communicate with technical people
• How to work in a group
• How to manage their time
• How to break projects down, estimate, and plan
• How to object or criticize without being a dick

Technical:

• Basic data structures (lists, hashs, heaps, etc.) Even if your language of choice implements these for you, they still shouldn't be black boxes.
• A few different algorithms & how to analyze run times. Not everyone needs to know sorting, but to be honest, so many people do, you're in a small minority if you don't.

Most things from there are hard to generalize. E.g., someone working on embedded controllers probably doesn't need to know SQL, likewise a DBA probably doesn't need to know the STL.

Every programmer should know the basic of the underlying hardware they work on. What is the difference between languages before choosing one. Know every inch of the language he works on. Know almost 10 different containers. Generic programming. basic Boolean logic, some basic mathematical principles. the 100 basic algorithms. And good goggling techniques.

BUT the top ability of a good programmer is the problem solving and out of the box thinking and believe me you can't learn this you are born with it.

Besides the obviuos:

Communication skills

Graphical, Spoken and Written.

Never Assume Anything. As in Stephen King's Cell ..Assume makes an ass out of U and Me

Beware the complicator!

a good developer must be able to;

• step back from the codeonce and awhile to look at the big picture
• explain what (and why) they are doing to a fellow developer and the office PA and the director and the marketing manager....
• understand that if the spec hasn't been changed by the time they are about to launch, something is inevitably/inherently wrong
• take developer crticism as a way of learning
• NEVER stop learning
• still get a buzz out of developing good software/code

Know when to stop.

Don't spoil a good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while.

-- From "The Pragmatic Programmer"

Although sometimes, I just can't help it and my hands are simply itching to optimize it a "little bit more". =)

Instead of pointing fingers, point to possible solutions. It's the positive outcome that counts.

(from: "Practices of an Agile Developer")

• SQL
• matlab
• one OO language
• one functional language
• one scripting language
• lex/yacc or similar parsing tools
• and maybe tex, prolog, vhdl, postscript

Just few hours or few days of exploring is enough. No need to be very familiar to these things.

The main point is to broaden the view of programmer: there are many kind of programming which is so different. Don't let the language you used limit your thinking.

My .02 cents worth......

Not knowing how you are going to design/code/accomplish a task while the client is asking for it is NOT reason enough to reject the client request. Sometimes we have to agree to do something BECUASE the client needs it ...and THEN find out HOW to do it.

As Patton once said: 'We are in business to do the impossible"....any slob can accomplish what's possible. That last part I added in ;))

Lots of great answers here, but I'll toss out one more: Do NOT rely on your job to improve your skills. Many programmers figure that five years' worth of following orders and bug-fixing work at a typical IT shop, doing CRUD programming, automatically makes them a "senior programmer". Not necessarily so: I like Jared Richardson's line, "Some programmers have gotten five years' experience. And some programmers have gotten one year's experience, five times."

Accept that is ultimately YOUR responsibility (NOT your boss's) to improve your skill set, learn new languages, and produce higher quality, well-designed code. This could mean writing your own tools at work, it could mean a side project done in your spare time, it could mean a new tech book a month, or it could mean contributing to an open source project. If you can find a project related to something you're passionate about, so much the better.

Whether you're salaried, or a contractor ... ultimately, we're ALL freelancers.

97 Things Every Programmer Should know: http://programmer.97things.oreilly.com/wiki/index.php/Edited%5FContributions

The existance of http://stackoverflow.com

How to use google

That you must eat your own dog food if you really want to make robust code.

Learn Lisp.

ESR nailed this one:

"languages of particular importance to hackers include Perl and LISP" ... "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."

I've never seen a Lisp programmer who couldn't very easily pick up any new language, though I've seen many, many programmers who specialized in every other imaginable language who had trouble learning new languages. There's something about Lisp that stretches one's brain. (I think it has to do with the circularity of defining something in itself.) Like a contortionist, nothing else seems like much of a stretch any more.

My college required all students to take courses in foreign languages and cultures, including non-western cultures. I'm amazed that we allowed people to graduate from the computer science school having only learned C++ and Java.

Yes, when hiring I rank this way above many of the other things here. Any Lisp programmer can learn "Source control, unit testing, and continuous integration" in almost no time, but a Java-only programmer who knows those 3 things may well struggle with closures, or parsers, or something that I actually need. If you know computer science and programming, we can teach you the processes, but not the other way around -- or at least, not on a timescale I'm willing to subsidize with payroll.

Speaking as a college grad, there are soooo many things I did not learn in school, which I had to pick up on my own. I could go on about the various things I had to learn on my own, but that might take a while :) Instead, I suggest that the following trumps any specific tool or technology:

Continue learning new things. You must have the drive for continuous improvement in order to remain sharp and competitive.

How to understand a program written in a programming language that you did not learn.

(for example, a Java programmer reading C# code without learning C#)

Funny, but I find the single most important skill in my work is googling. Sometimes I google problem even before I think about it :)
Or, if generalize, I'd call it 'information processing': ability to 'scan' lots of data quickly and find the information you need.

The Mother of All Demos

from Wikipedia

The Mother of All Demos is a name given retrospectively to Douglas Engelbart's December 9, 1968, demonstration at the Fall Joint Computer Conference (FJCC) at the Convention Center in San Francisco, in which a number of experimental technologies that have since become commonplace were presented. The demo featured the first computer mouse the public had ever seen, as well as introducing interactive text, video conferencing, teleconferencing, email, hypertext and a collaborative real-time editor.

1. Drop your ego

2. Criticism is not evil

3. Embrace failure

4. Recover from failure quickly

5. Practice, practice, practice ....

6. Be eager to learn from others

7. Be willing to change

Thinking out-of-the-box is usually a good thing! Most of the development is not just straightforward.

How to leverage their network of contacts both internally within their current organisation and externally, as you never know when you will need someone to mull over an issue with you or where the next interesting project might come from.