Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Regardless of programming language(s) or operating system(s) used or the environment they develop for, what should every programmer know?

Some background:

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.


migrated from Jul 10 '11 at 10:20

This question came from our site for professional and enthusiast programmers.

locked by Yannis Mar 13 '12 at 20:52

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

174 Answers 174

up vote 636 down vote accepted

How to swallow pride and admit mistakes without taking them personally.

That is something that every human being should do regardless of their job (, religion, culture, social status...), don't you think? ;) – Manrico Corazzi Sep 25 '08 at 12:00
Oh yes. But we programmers (at least I do) have a tendency to have more overt pride than most :-) – Gilligan Sep 25 '08 at 12:02
I wish i could vote you up twice. – JoshReedSchramm Sep 25 '08 at 15:27
I think this is one thing I learned at university. In highschool I was always one of the smart kids. If I hadn't gone to uni, I would have thought I was pretty smart and had a big ego. Going to uni, and interacting with people who were truly more skilled then I was helped me see just how dumb I was – Kibbee Sep 27 '08 at 1:45
While this is very true, the issue isn't always denial or a big ego, but the potential consequences of openly admitting to making mistakes, at least not without some sort of self defense/damage control first. Sometimes it's a cultural thing. :) – Emrah Dec 1 '09 at 14:00

I'm a little late to this one, but I'll go with the knowledge laid down by Edsger Dijkstra:

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

If you can't write a good paragraph, chances are you can't write good code either.

Yet I'm amazed at the terrible spelling, grammar, and punctuation used in natural-language writing by some programmers. You would think that working every day with systems that have zero tolerance for spelling errors and invalid syntax would have a beneficial effect... – cheduardo Jun 23 '09 at 13:07
@cheduardo, that's because once you compile or run a program, in most languages, you will be told about any spelling, grammar or punctuation errors, which can then be easily corrected. Not so for logical errors. – Inshallah Nov 5 '09 at 20:41
Agreee.. hmm... minus the "native tongue" part, some of us [unfortunately?] communicate better/clearer in our non-native tongues. – sjobe Apr 27 '10 at 22:03

Today I came across this book. It is a very nice book and a good recap of all the best practices.

97 Things Every Programmer Should Know

  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

  1. Debugging someone else's code
  2. How to test your own code
  3. Design with security in mind
  4. How/when to comment

Recommended reading list:

  • Writing code (with good practices is mind) makes you a better coder.
  • Constant study and debate.
  • Viewing problems from multiple angles.
  • Humility.
  • Knowing where to look if you don't know the right answer.

Where to find the information the programmer needs :)


Reading other peoples' code is not going to spoil your brain, but rather figure out why you would not have done it that way (if better or not is another question).

This gives you programming gedankenexperiment, and occasionally you do find someone implementing something way better! Like in way better.

This answer naturally expands to reading your own code, thus it expands to use version control and DIFF, and thus to 42.


Version control. And to quote my girl friend: "I don't just want you to do the dishes, I want you to like it!"


That the programmer doesn't know everything and should always try to learn new languages/technologies, etc.


Coffee and IntelliSense are your best friends ever.


Here's my 10 bits:

  • How to be humble. We are all here to learn. You may be smarter than others, but there are a lot of people smarter than you.
  • How to study/consume information. I don't know about you, but I am forever studying! Books, the Internet, whatever!
  • What a dictionary is and how to use one, and how to find out acronyms quickly.
  • What the basic tools of the trade are and what they do (IDE, CVS et al).
  • Know common terminolgy and what they mean: design patterns, usability, testing (ha!), stack, etc.
  • Have an understanding of OOP.
  • Be "capable" in at least one language, nothing amazing, just know how to identify variables and methods, etc. From here you can learn FAST.
  • Understand that people ultimately use software and want to make those people happy.
This must be an octal post. – Even Mien Sep 25 '08 at 16:26
Regarding the first bit.... "Don't be so humble, you're not that great". – Magnus Sep 25 '08 at 16:36
Regarding point 3: – Jasper Bekkers Dec 16 '08 at 17:42
@jasper/intuited: just type the acronym into google and it will pull up one or the other... the answer is usually in one of the first 10 results anyway. more info can be obtained by clicking! – mpen Apr 22 '10 at 4:57

I would like to quote the following only,

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan


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.


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.


How a veterinary doctor does his job!

While funny, very unrelated. – the_drow Jul 8 '10 at 8:24

It was mentioned before but I think it deserves it's own answer.

Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems. --"Jamie Zawinski", in comp.lang.emacs – Bjorn Reppen Sep 28 '08 at 21:11
Some people, when confronted with a regular expression, think “I know, I'll quote Jamie Zawinski.” Now they have two problems (one of which is that they probably don't know what they're doing in the first place). – Donal Fellows Oct 24 '10 at 20:38

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#)


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.


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.


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.


The fastest way to learn is the slowest. The slowest way to learn is the fastest.

In universtiy I was one of those guys who always asked the prof. for the formulas, for tricks and mnemonics to memorize the right answer, for the fastest way to solve the question, and this is my greatest regret.

Learning things by formulas and memorization means you start every problem at step one; you can't apply any of your previous solutions to new problems. I was no better at solving problems at graduation than I was as a freshman.

The guys who did best were the ones who learned how to do things from first principles; they derived the formulas instead of memorizing them, and would solve the same question multiple times to try different approaches and check their answers.

Yeah, at first those guys took forever to solve the simplest problems, but from then on they never had to solve them again, they knew it cold. By the final year they could solve many problems at a glance, and could estimate the right answer without working it out first.


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 most important thing you bring from college is NOT technological - The most important thing you learned is how to learn. The fact is that a large chunk of any specific technology you learned in college will be out of date in a few years, so your ability to learn and absorb new things is paramount.
  • Look for the bad in the buzz - it's nice to think that because something is new, it's better - but every technology has a downside and a limitation. Just because your first real-world corporate team isn't using the latest technology, it doesn't mean their heads are stuck in the sand - look for the reasons why and realize that serious redesign and techology rev won't happen at certain phases.
  • it's not about being the star, it's about being on the team - sort of a twist on the elite developer bullet - I'll take a team of 10 people who can cover each other's faults with strengths as a team over the 1 hot shot any day.
  • Asking good questions makes you look smart - conversely, handing in something way off the mark because you didn't ask a single question makes you look dumb. Check in early and often with others on your team, especially your designated lead. Restate the goals, even if you have no doubts you understand them, to confirm that you have the right idea. This isn't stupid, it's good communication. The more you can do this, the bigger and harder work you'll be given.

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


Think outside the box!

  • 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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.