Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

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

  • 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.
"Asking good questions makes you look smart " <-- This is a really good one! This applies really well to interviewing, too. – Brad Heller Apr 22 '10 at 16:13
"Look for the bad in the buzz" Boy do I see people who need to learn this one. Preferably before your whole system is based on something that works fine with 12 test records but which never perform well with the 20,000,000 records you wil have in year two. – HLGEM Apr 22 '10 at 20:26
I liked reading some of your answers, nicely said. – VoodooChild Apr 21 '11 at 2:28
  • 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.

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.


If you want to be the best possible programmer, you need to understand how the "magic" works. Others have suggested learning about compilers, and that's a good start. I would even say every serious programmer has to build their own compiler at least once. But there are other "magics" you need to understand:

  • How floating point maths work on the bit level
  • How an operating system manages processes and memory
  • How a CPU handles instructions internally (microcode, pipelining, branch prediction, ...)
  • How everything is built out of transistors, and how transistors work on the level of basic physics

I would also suggest studying "magical software techniques":

  • How game AI works, how a chess game plans its next move
  • Different sorting algorithms
  • Different techniques for laying out connected node graphs and finding paths in them

You should end up with a knowledge good enough to feel that you could look up everything you need to know to work on any part of the entire system. What this then will give you is a grounding that lets you tackle any issue, regardless of how many disciplines it traverses.

Ofcourse, this isn't all required to be a good programmer, but your question wasn't about being good, it was about being the best you can.

  • Source control, unit testing, and continuous integration are far more important than any clever algorithm.
My god, how did I miss that? This is a big one! – Brad Heller Apr 21 '10 at 19:44

Every programmer should understand that generally the best solution for the business and the most technically elegant programming solution are not the same thing.


Where to find the information the programmer needs :)


The fact that, No one is indispensable!


Managing expectations of your clients, your manager, your coworkers.


Your code will inevitably have some little thing you never thought of go wrong. Don't worry, it's ok, just fix it and learn from the experience.


All problems are people problems


Every programmer should know that:

a) maintainability should not be sacrificed for insignificant performance gains.

b) maintainability is better in the long run, even if it costs a little more up front.

c) maintainability generally does not cost more up front if you know what you're doing in the first place.


How to talk to non-programmers about programming concepts. It's tricky to get the hang of, but it will increase your value and the ease of your life greatly.


Do not be a complainer, solve the problem.

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

While helpful at times, you should not be fully relying on your compiler or your debugger to help you make your code better.




What you don't know.


Short and sweet -- no person will be an excellent coder / programmer / developer (pick your favorite word) unless he is a continuous learner.


How to establish good communication with management so that requirements and time frames are achievable and realistic.

Sadly, I've never seen anyone with good enough communication to get a realistic time frame on any project, ever. – Sean McMillan Dec 18 '09 at 12:38

One of the things that I try to recall whenever I'm writing code is that someone else will have to change it someday. Now, in certain instances, this may not be true, but I write as if it is. I try to code so that they can enjoy the process, or at least not give it a second thought.


Be language/platform agnostic. Java is not the right tool for all applications. Neither is C#, or C, or Lisp, or [insert your own language here]

Without users, there is no use for programmers

And one of my favorite quotes... Always write your code as if the next person to come along and support it is a raving lunatic who knows where you live.


My 2¢ as an aspiring hardware design guy:

you should know how a computer physically works, so that you understand where the power of software bumps up against the limits of hardware, and how to prepare for them, code around them, and come out ahead.


Stop worrying and start doing.


How to learn new things and adapt. I've watch us go from assembler to BASIC to FORTAN, to C, to C++ to Java to C# and so on. I've watched computers go from mainframe to desktops to embedded in just about everything.

I've seen computers go from being large calculator only a few people ever used to controlling almost everything in our daily lives. How many computers, microprocessors, and other programmable device did you interact with today? It may be hundreds!

I know a person with a CS degree they earned about 20 years ago. She has to ask her kids to help them send a e-mail or look up a web site. They could not adapt to the changes.

Your most important skill is learning.


That writing code is only a small part of being a programmer.


You can't bolt 'security' onto a product.


I think that a lot of people are reluctant to help or teach others what they know, and for me, this is, simply put, wrong on many levels.

First of all, one of the best ways to really learn something is to teach it to someone else...and it that someone else doesn't understand your explaining, then it means that you don't know it enough to explain it in simple terms.

If you really are passionate about your craft, why restrict what you know to yourself? I personally think that there is a social side to programming as well. Of course, we all like our late night coding sessions with a mug and an ashtray by our sides, but believe it or not, some time or another, you will find yourself working in a team. And when you are, why not mentor the ones that are less knowledgeable than you (about the respective subject), and teach them what you know so that they become better programmers?

After all, in the final product, better developers will develop a better solution.

...and besides, wouldn't you want other fellow developers giving you a few tips here and there, or even teaching you what they know? I suppose you would...I mean, if you wouldn't, then it just means that you don't love your craft and you are just doing it because there is nothing better to do

So anyways, my point is: Do not keep what you know to yourself...

  1. Algorithms and data structures - independent of language or platform (which always change)
  2. Google :)
  3. Top-down programming
  4. Bottom-up programming
  5. Concurrency and distributed computing
  6. Relational database theory and practical understanding of queries and database design, normalization.
  7. Human interface design principles and human factors.
  8. How to write clearly and simply to communicate information vs. sounding elegant.
  9. Testing principles and theory.

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